[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1002190912550.25964@router.home>
Date: Fri, 19 Feb 2010 09:14:00 -0600 (CST)
From: Christoph Lameter <cl@...ux-foundation.org>
To: "H. Peter Anvin" <hpa@...or.com>
cc: Yinghai Lu <yinghai@...nel.org>, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
Suresh Siddha <suresh.b.siddha@...el.com>
Subject: Re: [PATCH 34/35] x86: use num_processors for possible cpus
On Thu, 18 Feb 2010, H. Peter Anvin wrote:
> > As I have also repeatedly stated: Dynamic percpu data allocation when
> > onlining / offlining processors will complicate locking (cannot rely on
> > percpu be present anymore) and introduce numerous additional
> > hotplug notifiers into subsystems.
>
> I did state explicitly "on first up". Trying to free it would be
> insane. There are a couple of subsystems which are percpu memory
> pigs... so far it's not clear any of them actually matters in a
> production kernel. 60K * 16 phantom processors is still ~ 1 MB, which
> probably isn't enough to worry about but isn't great.
The first up still means the addition of notifiers for subsystems that
have to initialilze their per cpu data and dealing with potential races
that would be caused by adding those.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists