[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 3/3] memory-device: break the loop if tmp exceed
From: |
David Hildenbrand |
Subject: |
Re: [Qemu-devel] [PATCH 3/3] memory-device: break the loop if tmp exceed the hinted range |
Date: |
Mon, 29 Jul 2019 10:42:55 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 |
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 <address@hidden>
>>> ---
>>> 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
- Re: [Qemu-devel] [PATCH 2/3] memory-device: break the loop if no hint is provided, (continued)