This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: What *is* the API for sched_getaffinity? Should sched_getaffinity always succeed when using cpu_set_t?


Hi!
> > But I'm not 100% sure what the change did but it looks to me like this
> > changed kernel to create cpu sys entires for all sockets on the bus
> > rather than only for present ones.
> 
> Please look at /sys/devices/system/cpu/possible on your machine. It may be
> different from /sys/devices/system/cpu/cpuX.
> 
> Example, my x86 machine show:
> 
> $ cat /sys/devices/system/cpu/possible
> 0-31
> 
> $ find  /sys/devices/system/cpu -maxdepth  1 -name 'cpu[0-9]*'
> /sys/devices/system/cpu/cpu0
> /sys/devices/system/cpu/cpu1
> /sys/devices/system/cpu/cpu2
> /sys/devices/system/cpu/cpu3
> /sys/devices/system/cpu/cpu4
> /sys/devices/system/cpu/cpu5
> /sys/devices/system/cpu/cpu6
> /sys/devices/system/cpu/cpu7

No it's not different on any of my machines, but that is likely because
I have boring hardware that does not support cpu hotplugging.

> > It also looks like some time ago both calls were aliases and the only
> > source of information about available processors was /proc/cpuinfo.
> > (see git log on glibc sysdeps/unix/sysv/linux/getsysstats.c)
> 
> If running such old system, Linux doesn't have a hotplug feature. So, it is
> correct IMHO.
> 
> Ho hm, do you mean you are worry about chroot and/or namespace feature? If so,
> you are correct. If processes can't access /sys, /proc/cpuinfo might tell us
> wrong number of cpus information. But, is this serious? When /sys is no accessible,
> a lot of functions don't work correctly. It is not __get_nprocs_conf() specific.
> If it is unacceptable, we need to implement sysconf syscall, instead of using /sys.

Well, you need to mount at least three filesystems to make linux work in
chroot proc, dev and sys. But I'm not sure if sysconf syscall would be
acceptable, you know the mantra kernel people keeps repeating "It could
be done in userspace".

Perhaps we could introduce syscall to query sysfs values. It could take
sysfs path as identificator and userspace buffer and would return the
value, defacto shortcut for open(), read(), close() as it is done now.
That would simplify some things, but still I'm not sure whether this
would be acceptable.

> > Anyway this interface needs better description in manual pages. I can
> > prepare a patch once we are sure what information it returns.
> 
> Great!

Now we only need to figure out what exactly it does and make that into
understandable wording.

-- 
Cyril Hrubis
chrubis@suse.cz


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]