From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 565 invoked from network); 15 Apr 2020 09:57:39 -0000 Received-SPF: pass (mother.openwall.net: domain of lists.openwall.com designates 195.42.179.200 as permitted sender) receiver=inbox.vuxu.org; client-ip=195.42.179.200 envelope-from= Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with UTF8ESMTPZ; 15 Apr 2020 09:57:39 -0000 Received: (qmail 10064 invoked by uid 550); 15 Apr 2020 09:57:37 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 10043 invoked from network); 15 Apr 2020 09:57:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wnV2ZvFmQkyR/optyMSrmoYnYHLSxuAqRu/JkkXeOcs=; b=WesQfidg1Pf6LJybMS+KteUkEI9yQEO2MxkXQL9XktqiIrlcyQ1lzpnZ/kRVjV/dD8 yM8z/aOhGxc6YgLDVFq+dZWmPd2ndAS4N7MGUr3tPdsAdJzN8N5dTtEDjsohRQAjLyqT 7pjg6zP0dJWn6Q+aoDSh/ylY5X53arXGa6Ia8/jcIQF7zdpSY39s+xdx9fngllAHJ8p4 iGGDGTsLsBPddcYNb6zWAHO23Ij+YmeCEByiqFXn4FWxEaeHCRTj1z3LqEq6WUH7FJPv m5ULJTUFTBdbQbAnjWepSJ88SMoHppICFhGTcgVa5H80db+TjDdNHLb9BqTkZD6fQ54W 7vgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wnV2ZvFmQkyR/optyMSrmoYnYHLSxuAqRu/JkkXeOcs=; b=p3bhoBeOchfzZ7ZXXeOIOXGzMvQlxndaul+gi8oXUbu7kvRJe/Pbb5cTkbEfluXw4P fiUibf6CIHIMTeYQXeYJ3YrRTnjIm9mYzmesCons38stU9VfHSXVQzFywNO1ockVN7GW +z6+8Jvxlciw7wNYgiWX3viAbLtM6HsgTW2GDCQsv1ilUfboRDddJpQ65014mc49Masv dPVsANRMVHWaRT6/H903I2pfI2xM9juNC5QAzzfPoVtSC/XPQAGwPuzpAea5VGxRGjQA DdRS6UyvSD4L/bSvX7BeIRHuUTJXGL4Yv12msGiyeQClL7kKLkQLwGJOcQ9rTC2JCOVV r+0g== X-Gm-Message-State: AGi0PuYVCoBUJDRVUk5azmGjV0MeILEdhRqHuJKnI/DukZICRQm18HjP HjscKtj7AFM40H0ZQcfU8rrmeFlp2HoWQJD1J7k= X-Google-Smtp-Source: APiQypJ3vAYF/PhLYESUricYghk32CgUf5vfVcOWGvQmyfYPYuUEWvUXtKxFSWaVPuwqXJBvkj8BkvXPfvd2qTxlWd4= X-Received: by 2002:a6b:3842:: with SMTP id f63mr24017758ioa.90.1586944644635; Wed, 15 Apr 2020 02:57:24 -0700 (PDT) MIME-Version: 1.0 References: <20200409181824.GD13749@port70.net> <87r1wwik8t.fsf@mid.deneb.enyo.de> <20200410010255.GN11469@brightrain.aerifal.cx> <877dyinzuz.fsf@mid.deneb.enyo.de> <20200414155522.GB11469@brightrain.aerifal.cx> <87wo6iknx1.fsf@mid.deneb.enyo.de> <87o8rtjcwj.fsf@mid.deneb.enyo.de> In-Reply-To: <87o8rtjcwj.fsf@mid.deneb.enyo.de> From: Norbert Lange Date: Wed, 15 Apr 2020 11:57:16 +0200 Message-ID: To: Florian Weimer Cc: musl@lists.openwall.com, Rich Felker Content-Type: multipart/alternative; boundary="000000000000d2635405a3515761" Subject: Re: [musl] [BUG] sysconf implementing _SC_NPROCESSORS_(CONF|ONLN) incorrectly --000000000000d2635405a3515761 Content-Type: text/plain; charset="UTF-8" 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 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). > --000000000000d2635405a3515761 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 compila= tion fail by default, or not provide the function at all.
=
The implementation right now doesn't seem s= ufficient (to put it midly) and it prevents detection and automatic fallbac= ks. For example trace-cmd would do this, and would work nicely - but instea= d it will gets musls implementation that's defeated by setting an affin= ity mask.=C2=A0

Florian Weimer <fw@deneb.enyo.de> schrieb am Mi., 15. Apr. 2020, 11:50:
* Norbert Lange:

> How should=C2=A0 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,<= br> > 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<= br> > 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<= br> code that is expected to be linked statically into applications.

Given that, I'm not sure that glibc's way is a significant
improvement.=C2=A0 musl should perhaps be changed to cope more gracefully with a sched_getaffinity failure, though (by not reporting a UP
environment by accident).
--000000000000d2635405a3515761--