public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Yinghai Lu <yinghai@kernel.org>,
	Jesse Brandeburg <jesse.brandeburg@gmail.com>,
	Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	NetDEV list <netdev@vger.kernel.org>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>
Subject: Re: [PATCH 2/2] x86: get more exact nr_irqs
Date: Mon, 04 Jan 2010 12:05:08 -0800	[thread overview]
Message-ID: <m1skald4az.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <4B4241E2.1020008@zytor.com> (H. Peter Anvin's message of "Mon\, 04 Jan 2010 11\:30\:42 -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

  parent reply	other threads:[~2010-01-04 20:05 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-25  8:42 [PATCH] x86: increase NR_IRQS and nr_irqs Yinghai Lu
2009-12-28  9:47 ` Ingo Molnar
2009-12-29  5:08   ` [PATCH -v2] " Yinghai Lu
2009-12-30 12:21     ` [tip:x86/apic] x86: Increase " tip-bot for Yinghai Lu
2010-01-04  3:06     ` [PATCH -v2] x86: increase " Jesse Brandeburg
2010-01-04  3:20       ` Yinghai Lu
2010-01-04  6:56         ` Subject: [PATCH 1/2] x86: get back 15 vectors Yinghai Lu
2010-01-04 16:18           ` Eric W. Biederman
2010-01-04 18:40             ` Yinghai Lu
2010-01-04 19:04               ` Eric W. Biederman
2010-01-04 19:14                 ` H. Peter Anvin
2010-01-04 19:01             ` H. Peter Anvin
2010-01-04 19:09               ` Eric W. Biederman
2010-01-04 19:35                 ` Yinghai Lu
2010-01-04 19:45                   ` Suresh Siddha
2010-01-04 19:50                     ` H. Peter Anvin
2010-01-05  0:05                       ` Suresh Siddha
2010-01-05  0:16                         ` Yinghai Lu
2010-01-05  5:30                           ` [tip:x86/apic] x86, apic: Reclaim IDT vectors 0x20-0x2f tip-bot for H. Peter Anvin
2010-01-04 19:48                   ` Subject: [PATCH 1/2] x86: get back 15 vectors H. Peter Anvin
2010-01-04 20:06                     ` Yinghai Lu
2010-01-04 20:14                       ` Eric W. Biederman
2010-01-04 20:33                         ` Yinghai Lu
2010-01-04 21:10                           ` H. Peter Anvin
2010-01-04 21:20                             ` Yinghai Lu
2010-01-04 21:33                               ` H. Peter Anvin
2010-01-04 22:01                                 ` Yinghai Lu
2010-01-04 23:03                                   ` H. Peter Anvin
2010-01-04 23:32                                     ` Yinghai Lu
2010-01-04 23:38                                       ` H. Peter Anvin
2010-01-04 23:42                                         ` Yinghai Lu
2010-01-04 23:49                                         ` Yinghai Lu
2010-01-04 23:59                                           ` H. Peter Anvin
2010-01-05  5:30                                   ` [tip:x86/apic] x86, apic: Don't waste a vector to improve vector spread tip-bot for H. Peter Anvin
2010-01-04 20:08                   ` Subject: [PATCH 1/2] x86: get back 15 vectors Eric W. Biederman
2010-01-04  6:58         ` [PATCH 2/2] x86: get more exact nr_irqs Yinghai Lu
2010-01-04 16:55           ` Eric W. Biederman
2010-01-04 19:03             ` Yinghai Lu
2010-01-04 19:16               ` Eric W. Biederman
2010-01-04 19:30                 ` H. Peter Anvin
2010-01-04 19:47                   ` Yinghai Lu
2010-01-04 20:05                   ` Eric W. Biederman [this message]
2010-01-04 21:50                     ` H. Peter Anvin
2010-01-04  6:59         ` [PATCH 1/2] x86: get back 15 vectors Yinghai Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1skald4az.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=jesse.brandeburg@gmail.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=netdev@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox