[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADYdroNF11=SCxyjJ2i7=cyjVTV0N6tNrYG8Ly2McrSDBsks6w@mail.gmail.com>
Date: Wed, 15 Apr 2020 11:57:16 +0200
From: Norbert Lange <nolange79@...il.com>
To: Florian Weimer <fw@...eb.enyo.de>
Cc: musl@...ts.openwall.com, Rich Felker <dalias@...c.org>
Subject: Re: [BUG] sysconf implementing _SC_NPROCESSORS_(CONF|ONLN) incorrectly
I can't comment on whether glibc should be emulated. The point I am trying
to make is that it might be better to let the compilation fail by default,
or not provide the function at all.
The implementation right now doesn't seem sufficient (to put it midly) and
it prevents detection and automatic fallbacks. For example trace-cmd would
do this, and would work nicely - but instead it will gets musls
implementation that's defeated by setting an affinity mask.
Florian Weimer <fw@...eb.enyo.de> schrieb am Mi., 15. Apr. 2020, 11:50:
> * Norbert Lange:
>
> > How should one deal with this?
> > I understand that the semantics are vague, but given that musl now
> > implements this
> > function, it will make detection and fallback hard (especially as musl
> > doesn't wants to be identified by the likes of macros).
> >
> > As it is now, just using the affinity mask definitely cant be useful,
> > an application wanting that behavior should be patched to
> > use that function directly.
> > If musl would not define the _SC_NPROCESSORS_* macros (but still keep
> > the implementation),
> > this could be used for compile-time detection atleast. Enabling the
> > current implementation would be
> > just a matter of explicitly defining those macros.
>
> _SC_NPROCESSORS_* as implemented in glibc is bad because those values
> are not adjusted by cgroups, so it can grossly overestimate available
> resources.
>
> The cgroups interfaces themselves are not stable and very complicated.
> I don't think it's a good idea to target them, especially not from
> code that is expected to be linked statically into applications.
>
> Given that, I'm not sure that glibc's way is a significant
> improvement. musl should perhaps be changed to cope more gracefully
> with a sched_getaffinity failure, though (by not reporting a UP
> environment by accident).
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
