[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1002181340380.7486@router.home>
Date: Thu, 18 Feb 2010 13:48:37 -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:
> > per_cpu setup will allocate some mem for every cpu according to possible cpus.
> >
>
> Yes, and I have repeatedly requested that we allocate the memory on the
> first up of a disabled CPU rather than eagerly, but in *most*
> configurations the amount is relatively small.
The size of the static per cpu segment is likely around 30k and you will
likely add another 30k in dynamic allocations.
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.
Newly allocating a per cpu segment also has consequences for subsystems
that dynamically allocate per cpu data (not add another cpu but
dynamically allocate data that needs to be present on all processors).
They would have to prepare the per cpu data which would create another
need for callbacks.
All of the measures necessary would result in problems of ensuring object
existence in critical code paths that use percpu data for performance
reasons.
--
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