Re: Use sched_getaffinity instead of /proc parsing for _SC_NPROCESSORS_ONLN

Hi,

On Mon, December 6, 2010 22:49, Bela Lubkin wrote:
> Deciding these things based on OS name & version is so '90s.  Instead of
> adding an OS define that only controls one feature, it should key off of
> a feature define: USE_GETAFFINITY_CPU_COUNT or something like that.
> Except...
>
> The setting of *that* could be controlled by a "_HAVE_LINUX26"; but what
> are you really testing?  Red Hat adds the affinity calls to their 2.4
> kernels (RHEL3); other distros probably also did.

Well, dietlibc is Linux only, and Linux supports sched_[sg]etaffinity(2)
since 2.5 something. Red Hat's 2.4 is half 2.5 with a lot of stuff
backported, I wouldn't really call it 2.4.

USE_GETAFFINITY_CPU_COUNT is a better choice indeed though, or
USE_GETAFFINITY_FOR_SYSCONF_NRCPUS or something.

> It seems to me: (1) it is desirable to have working get/setaffinity() on
> any kernel that supports them; (2) it is desirable to have stubs [ignore
> set(), return 1 from get()] on kernels that don't support them; (3) if
> getaffinity always exists, there is no reason to #ifdef this code at
> all.  Except conservatism, and the possibility that some kernel / arch
> might have a better way.

The syscalls are always there, you just might get ENOSYS.

When that happens the new function returns 1, so 1 and 2 are covered.

The reason to ifdef is that if you don't have a working affinity,
you can parse /proc instead of returning 1.

The combination of 2.4 kernel and sysconf(SC_NPROCESSORS_ONLN) might
be unlikely enough to just ge rid of the proc parsing.

> For conservatism, `#ifdef USE_CLUMSY_OLD_PROC_SC_NPROCESSORS_ONLN' the
> old code :).  For other arches, well -- if there's a better way someone
> can add code for it, including the necessary #ifdef's...

That's probably the better approach.

What other arches? I think getaffinity supported on all arches,
just not on very old kernels.

> Other than that, the patchset (as revised) looks reasonable after a
> lightweight review.

Thank you for the review.

Indan