From: Tejun Heo <tj@kernel.org>
To: linux-ia64@vger.kernel.org
Subject: Re: [RFC] increase ia64 static per cpu area
Date: Tue, 27 Jul 2010 08:39:39 +0000 [thread overview]
Message-ID: <4C4E9B4B.1080801@kernel.org> (raw)
In-Reply-To: <4c4e0a40170612ea22@agluck-desktop.sc.intel.com>
Hello,
On 07/27/2010 12:20 AM, Luck, Tony wrote:
> I've been trying to avoid this for a long time ... but per-cpu space
> has slowly been growing. Tejun has some patches in linux-next that
> pre-reserve some space (PERCPU_DYNAMIC_EARLY_SIZE) for use before
> slab comes online ... and this pushes ia64 above the 64K current
> limit on static percpu space.
Yeah, more stuff are moving to percpu area. I'm thinking about
increasing PERCPU_DYNAMIC_RESERVE too as it's overflowing in most
common cases now, but it's not really a bad thing tho. Many of those
used to use NR_CPUS allocations instead so overall I don't think we're
wasting memory.
> I could probably squeeze it back under (we are only over by 512 bytes).
> But I don't think that I'll be able to squeeze it down enough to build
> a comfortable breathing space - and I don't want to keep nibbling off
> a dozen bytes here and there every time some generic code bumps us
> back over the limit.
>
> Next available supported page size is 256K ... so we have to quadruple
> the available space - a bigger jump than I'd like. But perhaps it will
> be enough to last a few more years before it needs to be increased again.
>
> Signed-off-by: Tony Luck <tony.luck@intel.com>
Acked-by: Tejun Heo <tj@kernel.org>
I suppose this would go through ia64 tree?
Thank you.
--
tejun
next prev parent reply other threads:[~2010-07-27 8:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-26 22:20 [RFC] increase ia64 static per cpu area Luck, Tony
2010-07-27 8:39 ` Tejun Heo [this message]
2010-07-28 20:48 ` Tony Luck
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=4C4E9B4B.1080801@kernel.org \
--to=tj@kernel.org \
--cc=linux-ia64@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.