Messages in this thread | | | Subject | Re: [PATCH 2/2] x86: get more exact nr_irqs | From | (Eric W. Biederman) | Date | Mon, 04 Jan 2010 12:05:08 -0800 |
| |
"H. Peter Anvin" <hpa@zytor.com> writes:
> On 01/04/2010 11:16 AM, Eric W. Biederman wrote: >> >> If we care about memory use efficiency let's replace irq_desc_ptrs >> with a rbtree or a radix_tree. Something that moves the memory use >> penalty onto those machines that have a lot of irqs. >> > > rbtree doesn't make much sense for something that is addressed by index, > and doesn't need to answer questions of the form "give me the highest > member <= X". A hash table or radix tree makes sense, depending on the > expected sparseness of the index.
Not counting irqs for msi's I think we are looking 36% to 25% fill. Maybe a little lower. The sparseness is much higher if we count the number of irqs that we might/use allocate as we do today.
Short of driver hotplug msis should be allocated densely, unless we start reserving all possible 4K msi-x vectors.
For each ioapic we allocate 16 gsis, and only maybe four of them are connected to actual pci slots.
This is essentially a slow path operation, so as long as we are not too expensive we can use any data structure we want. In kernel hash tables don't grow well so I don't think a hash table is a good choice, and a hash table is essentially what we have now.
The truth is we don't know how many irqs we will have until msi supporting drivers claim all of theirs.
I think a radix-tree would likely be the least intrusive choice as it does not imply any changes to the data structure indexed.
Eric
| |