When hotplug is complied, num_possible_cpus() is NR_CPUS. (atleast in x86_64/ia64) If /proc/config.gz can be relied on, maybe you can use that to get NR_CPUS and assume that as the max? Otherwise, I would think just add more info to /sysfs under cpu dir... Cheers, ashok raj - Open Source Technology Center >-----Original Message----- >From: hotplug_sig-bounces@xxxxxxxxxxxxxx [mailto:hotplug_sig-bounces@xxxxxxxxxxxxxx] On Behalf Of >David Lively >Sent: Wednesday, June 15, 2005 8:27 AM >To: Silbermann, Martine >Cc: hotplug_sig@xxxxxxxxxxxxxx >Subject: Re: [Hotplug_sig] MINUTES for Hotplug SIG Con Call 06/07 > >[Sorry for my long absence and complete lack of participation. Been >swamped getting our first release out the door ...] > >I've *finally* adjusted my 'top' patch so that it applies to the latest >version (procps-3.2.5). I've attached the updated patch and am >submitting it to the 'top' maintainer (albert@xxxxxxxxxxxxxxxxxxxxx, >according to http://procps.sf.net). > >There is one bit of ugliness: I hardcode Cpu_max to 128, then >dynamically allocate data structures based on this. I'd rather query >the system for the maximum number of possible CPUs and use this instead >of 128. It looks like this should be: > sysconf(_SC_NPROCESSORS_CONF) >but unfortunately that returns the same result as: > sysconf(_SC_NPROCESSORS_ONLN) >(Both seem to be deriving their results from a read of /proc/stat ...) > >Anyone know of a way to access (essentially) num_possible_cpus() from >userspace? > >Thanks, >David > > >Silbermann, Martine wrote: >> Mary asked if the patch that Virtual Iron submitted for TOP to avoid >> that TOP crashes when CPUs are offlined had been accepted in mainline. >> Apparently not....more investigation required. >> AR for Mary: who is the TOP maintainer?
