[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 08/27] ARM: GICv3 ITS: introduce host LPI array
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@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |