public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@osdl.org>,
	"Protasevich, Natalie" <Natalie.Protasevich@unisys.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86_64: Double the per cpu area size
Date: Mon, 07 Aug 2006 10:31:31 -0600	[thread overview]
Message-ID: <m1vep4ecd8.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <200608071730.47120.ak@suse.de> (Andi Kleen's message of "Mon, 7 Aug 2006 17:30:47 +0200")

Andi Kleen <ak@suse.de> writes:

>>  
>>  #include <asm/pda.h>
>>  
>> +#define PERCPU_ENOUGH_ROOM 65536
>
> I would prefer if you didn't do that unconditionally. Can you make
> it dependent on NR_IRQS or so?  Can you add a test for CONFIG_TINY
> to make it smaller?

We already ignore this variable for the per cpu allocation if we
build a kernel wihtout module support.  I guess a good fix could
entail changing the concept to be how much per cpu room to reserve
for modules.

I'm a big believer in stupid and simple solutions for as long as
you can get away with it.  When people trip over this then 
it will be clear what the real problem is and we can fix it.

> Also longer term it should really properly fixed

Agreed.  But we need a solution that works now so we have a solution
for when the 2.6.19 window opens up.  There is no agreement on even
what a proper fix is, or even what it looks like.  Keeping the data
per cpu seems about as good as anything else for memory size savings,
as most systems don't have many cpus.

Throwing a few more bytes at the problem solves it today and for
all systems currently built.  This buys us time to look at and discuss
the problem.  With MSI starting to be useful I have no expectation
that we will stop here.

There are two fundamental problems that need to be fixed.
- Small size and static allocate of the per cpu area.
- Data structures that don't scale to large numbers of possible irqs.

Solving either of these two fundamental problems involves reexamining
some of our current trade offs in the kernel.

The proper fix for irqs is a refactoring of the data structures so
we can handle a 16 or better yet a 24 bit irq number, and only
allocate the pieces we need.  A proper fix needs to find someway
not to keep a counter for every cpu and irq pair, which no one has
the will to seriously consider right now.

The proper fix for the per cpu area size is much trickier.
Especially if we every reach the point of hotplug NUMA nodes.
One odd observation is that the amount of per cpu data we want
grows with the size of the system.  

Eric

  reply	other threads:[~2006-08-07 16:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-07 15:25 [PATCH] x86_64: Double the per cpu area size Eric W. Biederman
2006-08-07 15:30 ` Andi Kleen
2006-08-07 16:31   ` Eric W. Biederman [this message]
2006-08-08 20:43     ` Keith Mannthey
2006-08-08 21:09       ` Eric W. Biederman
2006-08-08 21:26         ` Keith Mannthey

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=m1vep4ecd8.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=Natalie.Protasevich@unisys.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.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