This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: What *is* the API for sched_getaffinity? Should sched_getaffinity always succeed when using cpu_set_t?
- From: chrubis at suse dot cz
- To: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 18 Jul 2013 13:05:05 +0200
- Subject: Re: What *is* the API for sched_getaffinity? Should sched_getaffinity always succeed when using cpu_set_t?
- References: <51E42BFE dot 7000301 at redhat dot com> <51E4A0BB dot 2070802 at gmail dot com> <20130716110445 dot GA20826 at rei> <CAHGf_=qxR-abdjwmJUw8vApSioDhKhvsc54Yx-fpw5V-whpioQ at mail dot gmail dot com> <51E5DCB2 dot 1070305 at gmail dot com> <20130717100527 dot GA24881 at rei> <51E6EA7E dot 6050601 at gmail dot com>
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