[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.