From: "H. Peter Anvin" <hpa@zytor.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>,
Andi Kleen <andi@firstfloor.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
"ananth@in.ibm.com" <ananth@in.ibm.com>,
Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -v2 5/5] x86: use dmi check to treat disabled cpus as hotplug cpus.
Date: Wed, 13 Jan 2010 15:13:20 -0800 [thread overview]
Message-ID: <4B4E5390.1070004@zytor.com> (raw)
In-Reply-To: <4B4E511C.1050609@kernel.org>
On 01/13/2010 03:02 PM, Yinghai Lu wrote:
> On 01/13/2010 02:49 PM, Suresh Siddha wrote:
>> On Wed, 2010-01-13 at 14:36 -0800, H. Peter Anvin wrote:
>>> On 01/13/2010 02:29 PM, Suresh Siddha wrote:
>>>>>
>>>>> Well, that *is* working around broken code, in this case the broken code
>>>>> is the percpu allocation strategy.
>>>>
>>>> Andi, Recently percpu folks changed the per-cpu static first chunk to
>>>> PMD SIZE right. I think that is what causing all this issue.
>>>>
>>>
>>> Please don't tell me we're allocating 2 MB per CPU and throwing away
>>> most of it...
>>
>> Looking at the percpu code, they do seem to free the unused memory in
>> that hole.
>>
>> Yinghai, what are the configurations that need MB's of per cpu area?
>
> please check attached...
>
I just built an allyesconfig kernel, and it has 1904K of percpu data.
1791K of that is in per_cpu__cpu_lock_stats. So everything else is
~113K. Still. We should not be restricted from doing legitimately
large percpu allocations because of ghost cpus (and Tejun knows my
position on this), but it doesn't sound like the house is burning, either.
-hpa
next prev parent reply other threads:[~2010-01-13 23:14 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-12 23:17 [PATCH 0/5] clean up logical flat apic mode using Yinghai Lu
2010-01-12 23:17 ` [PATCH -v2 1/5] use nr_cpus= to set nr_cpu_ids early Yinghai Lu
2010-01-12 23:17 ` [PATCH 2/5] x86: using logical flat for amd cpu too Yinghai Lu
2010-01-12 23:17 ` [PATCH -v2 3/5] x86: according to nr_cpu_ids to decide if need to leave logical flat Yinghai Lu
2010-01-12 23:17 ` [PATCH -v2 5/5] x86: use dmi check to treat disabled cpus as hotplug cpus Yinghai Lu
2010-01-12 23:56 ` Suresh Siddha
2010-01-13 0:05 ` Yinghai Lu
2010-01-13 1:48 ` Suresh Siddha
2010-01-13 1:55 ` Yinghai Lu
2010-01-13 2:06 ` Suresh Siddha
2010-01-13 2:13 ` Yinghai Lu
2010-01-13 2:21 ` Suresh Siddha
2010-01-13 2:26 ` Yinghai Lu
2010-01-13 21:46 ` Andi Kleen
2010-01-13 22:00 ` H. Peter Anvin
2010-01-13 22:23 ` Andi Kleen
2010-01-13 22:27 ` H. Peter Anvin
2010-01-13 22:29 ` Suresh Siddha
2010-01-13 22:36 ` H. Peter Anvin
2010-01-13 22:49 ` Suresh Siddha
2010-01-13 23:02 ` Yinghai Lu
2010-01-13 23:13 ` H. Peter Anvin [this message]
2010-01-13 23:52 ` Andi Kleen
2010-01-14 9:25 ` Andi Kleen
2010-01-12 23:17 ` [PATCH 4/5] x86: make 32bit apic flat to physflat switch like 64bit 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=4B4E5390.1070004@zytor.com \
--to=hpa@zytor.com \
--cc=akpm@linux-foundation.org \
--cc=ananth@in.ibm.com \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--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