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]
Date:	Fri, 20 Feb 2009 11:45:58 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Andrew Morton <akpm@...ux-foundation.org>, rusty@...tcorp.com.au,
	tglx@...utronix.de, x86@...nel.org, linux-kernel@...r.kernel.org,
	hpa@...or.com, jeremy@...p.org, cpw@....com
Subject: Re: [PATCH 09/10] percpu: implement new dynamic percpu allocator

Ingo Molnar wrote:
> * Andrew Morton <akpm@...ux-foundation.org> wrote:
> 
>>> + * To use this allocator, arch code should do the followings.
>>> + *
>>> + * - define CONFIG_HAVE_DYNAMIC_PER_CPU_AREA
>>> + *
>>> + * - define __addr_to_pcpu_ptr() and __pcpu_ptr_to_addr() to translate
>>> + *   regular address to percpu pointer and back
>>> + *
>>> + * - use pcpu_setup_static() during percpu area initialization to
>>> + *   setup kernel static percpu area
>>> + */
>> afacit nobody has answered your "is num_possible_cpus() ever a 
>> lot larger than num_online_cpus()" question.
>>
>> It is fairly important.
> 
> yeah.
> 
> On x86 we limit num_possible_cpus() at boot time from NR_CPUS to 
> the BIOS-enumerated set of possible CPUs - i.e. the two will 
> always be either equal, or be very close to each other.
> 
> ( there used to be broken early BIOSes that enumerated more CPUs 
>   than needed but it's very rare and because it also wastes BIOS 
>   RAM/ROM it's something they'll usually avoid even if they dont 
>   care about Linux. )
> 
> So this should be a pretty OK assumption.

Hmm... this is a confusing conversation.  Andrew seems to say that not
allocating memory for offline cpus is fairly important and Ingo's
reply starts with yeah but draws the opposite conclusion.  Or my
English failing me again?

Thanks.

-- 
tejun
--
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