lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ