On 29.07.19 10:30, Wei Yang wrote:
> On Mon, Jul 29, 2019 at 09:49:37AM +0200, David Hildenbrand wrote:
>> On 28.07.19 15:13, Wei Yang wrote:
>>> The memory-device list built by memory_device_build_list is ordered by
>>> its address, this means if the tmp range exceed the hinted range, all
>>> the following range will not overlap with it.
>>>
>>> Signed-off-by: Wei Yang <richardw.y...@linux.intel.com>
>>> ---
>>> hw/mem/memory-device.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/hw/mem/memory-device.c b/hw/mem/memory-device.c
>>> index 413b514586..aea47ab3e8 100644
>>> --- a/hw/mem/memory-device.c
>>> +++ b/hw/mem/memory-device.c
>>> @@ -180,7 +180,7 @@ static uint64_t
>>> memory_device_get_free_addr(MachineState *ms,
>>> range_make_empty(&new);
>>> break;
>>> }
>>> - } else if (!hint) {
>>> + } else if (!hint || range_lob(&tmp) > range_upb(&new)) {
>>> break;
>>> }
>>> }
>>>
>>
>> Lower bound is inclusive, upper bound is exclusive. Shouldn't this be
>>
>> range_lob(&tmp) >= range_upb(&new)
>>
>
> Per my understanding, a range with start = 0, size = 0x10000, is represented
>
> [0, 0xffff]
>
> So if I have another range [0xffff, 0x1ffff], they seems to overlap. The range
> [0x10000, 0x1ffff] doesn't overlap with [0, 0xffff].
>
> My original comparison looks right. Do I miss some point?
I guess you saw my other reply by now. :)
>
>> Also, I wonder if patch #2 is now really needed?
>>
>
> Hmm... I think you are right.
>
> I am afraid without Patch #2, the condition check is not that intuitive. Would
> this bring some confusion for audience and maintenance?
Less checks, less confusion :)
>
> I am not sure the percentage of occurrence when hint is provided, while the
> generated code for check NULL is less than compare two values.
Nobody should care about that performance difference here.
I guess it is fine to just drop patch #2.
Thanks!
--
Thanks,
David / dhildenb
