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
