Re: [PATCH v2 08/27] ARM: GICv3 ITS: introduce host LPI array

[Julien Grall <julien.grall@arm.com>]

Hi Stefano,

On 22/03/2017 23:38, Stefano Stabellini wrote:
> On Thu, 16 Mar 2017, Andre Przywara wrote:

[...]

>> +    dev->host_lpis = xzalloc_array(uint32_t,
>> +                                   DIV_ROUND_UP(nr_events, LPI_BLOCK));
>> +    if ( !dev->host_lpis )
>> +        goto out_unlock;
>
> The expectation is that we are going to allocate far more than 32 lpis
> for one device, possibly thousands, right?
> If so, dev->host_lpis could be quite large. I am thinking we should
> consider switching to a sparse data structure to save memory, as in most
> cases the allocated blocks are going to be consecutive.
>
> I would probably store the first lpi and the number of consecutive lpis,
> rather than the first lpi in each block. For example, if the allocated
> blocks are:
>
>  0-31, 32-63, 64-95, 96-127, 128-159, 256-287
>
> Now we store: 0, 32, 64, 96, 128, 256
> I would store [0, 160], [256, 32]
>
> In the case of a thousand consecutive block allocations, it would
> shorten the array from 1000/32 to 1 element.
>
> Does it make sense? Is it worth doing? This last question is mostly for
> the Qualcomm and Cavium guys on the list because it depends on the
> numbers of events on a given platform.

Not answering directly to the question. But I think this is an 
improvement and not necessary for a first version.

I would like to see this series merged in Xen 4.9 as a tech preview, so 
I would suggest to gather this list of improvement (maybe on Jira?) and 
defer them for Xen 4.10. They would need to be addressed before making 
ITS stable. Stefano, does it sound good to you?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel