From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from caracal.birch.relay.mailchannels.net (caracal.birch.relay.mailchannels.net [23.83.209.30]) by sourceware.org (Postfix) with ESMTPS id 61DA43858410 for ; Fri, 17 Mar 2023 11:15:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 61DA43858410 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 082395C1074; Fri, 17 Mar 2023 11:15:30 +0000 (UTC) Received: from pdx1-sub0-mail-a307.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 88E2A5C10B2; Fri, 17 Mar 2023 11:15:29 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1679051729; a=rsa-sha256; cv=none; b=w5h6apnQeTn0bfolaQdT1UFDbxOmmzj+Ek2tIT4QtjhMsSLYSTjeY2Qq1iwg5F4oJTBmw1 IS9DrN6h9Jerl6X9mANk5pHmupadIbkcNbo8ufRTBJJl5ME7I+6PR+cVgJzwJ8oEW8PHyD LvsJP0AhRFQlEKl0S3IK1raz77TBB0PjYCKjA/WPht/qWZxy9iFoPiey+fb/qyJYS4D2P8 2qTlTk+O2f8eVff/J0TO9n8dbydq1jiLX9RRrNsMQnLV2YYxwoNpqEnSY6C2fhoDvLtMYQ MLWh0DiEwOLyC8YEP+Vy9wdTBr5i+SfGsa0ctLMl5cfLJRO87EXs20j94zZ54Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1679051729; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ej+ZGbFCACXGthzhB1iyWAAa+NxG8KC4tVZt89/cCvE=; b=xRnA0PWB+/YgoWSczlXzVLKn3oN6rZXEX5bm3bQaKu45oKa40OySoBYUQje4JcWRIt6bYK OxTIttvZkcHaiEigPu2nmWigWAIXkK4GiJEREEP1A5Xen4t0KH/XJRB889UB6uJPA8wm+b CGg5PpLDRpt8Ng1W/dPK25YIaHvwpN0Us6cW4rpDZKyZ435KzuyK2osYiiZ5Kjp10HnSV5 4dkNQrRMAzYa90cCG3sZP8wbNDFYXrw1iSB4/w58SairFZwi0knnXUl1Uf6mB7bJgmUZto 2Y/CC+r4PyEYI40YQNwjFreizcpeZ70lkb/PWgL85YIWcN6opyRcUh0tFdsxxQ== ARC-Authentication-Results: i=1; rspamd-766d96cb5b-z6rzz; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Grain-Whistle: 56febc42778d4753_1679051729829_738759263 X-MC-Loop-Signature: 1679051729829:4272468733 X-MC-Ingress-Time: 1679051729828 Received: from pdx1-sub0-mail-a307.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.117.156.21 (trex/6.7.2); Fri, 17 Mar 2023 11:15:29 +0000 Received: from [192.168.0.182] (bras-vprn-toroon4834w-lp130-09-174-91-45-153.dsl.bell.ca [174.91.45.153]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a307.dreamhost.com (Postfix) with ESMTPSA id 4PdM4K0vXrz1s; Fri, 17 Mar 2023 04:15:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1679051729; bh=ej+ZGbFCACXGthzhB1iyWAAa+NxG8KC4tVZt89/cCvE=; h=Date:Subject:To:From:Content-Type:Content-Transfer-Encoding; b=aLacJKebANyms9AiIPdA+kVie/QErOyMD6G/aDVqp1xs7GIVSkpIUj4nqauTgTSvM OrRzysJin2hPQskJew62fW1ciAANMUx0VWRKy4CycSUPdyBUMfcpFaTdMUp6WVe+K/ pINQG8JGn3s/12mYU59KnAgFl/DKFoWAhGR2JxLUhE0zYnUqXTr6/fPuIn4HuZHNjH xXQXjwDfjxIeI5CawqDwZDMk4TRpNx7kEfcKGsvsmv8+uY9klqeNvLRZhADOb4SNCa vMGdD2WhGtNOBLyocRI6jpfoQcX5i5GtTCpRq7Ng56YYPTbPlZ6yCUR9YM86WzBCuB w324TfaSx6asQ== Message-ID: <6b880467-e122-d2c5-f8d6-1394a4065753@gotplt.org> Date: Fri, 17 Mar 2023 07:15:27 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH 0/2] Make tunable a default feature Content-Language: en-US To: Adhemerval Zanella Netto , libc-alpha@sourceware.org, Florian Weimer References: <20230313190627.2000578-1-adhemerval.zanella@linaro.org> <6511a415-b165-586d-b22d-80ff4eef0fa8@gotplt.org> From: Siddhesh Poyarekar In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3030.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2023-03-15 16:05, Adhemerval Zanella Netto wrote: > On 14/03/23 15:02, Siddhesh Poyarekar wrote: >> On 2023-03-13 15:06, Adhemerval Zanella wrote: >>> It is enabled as default since 2.26, some features option require it >>> (such as hwcap mask, huge pages support, and lock elisition tuning), >>> and assuming its support also simplifies the build permutation. >> >> from a historical perspective, there was not just the question of enabling tunables but also providing multiple ways to read tunables, each having its own parser.  That is why there's a 'valstring' as an option for --enable-tunables. > > Does it really make sense to provide such option, where multiple distributions > would support different tunables? I don't this much as way forward, it would require > additional effort to document, along with some prudence to make it concise. And > its has the inherent problem of fragmentation. Yeah I agree it doesn't make a lot of sense anymore; I think we made it like that to bake in some flexibility for use cases we weren't aware of yet. I mentioned it here in the hope that folks who were part of the conversation then and have better memory than I would be able to pitch in with additional context :) >> Over the years there haven't really been any other ideas to read tunables.  There's the idea of systemwide tunables through, e.g. ld.so.conf that we'd like to have at some point, but that is more effective alongside valstring than as an either-or feature. > > For ld.so cache, the program can use DF_1_NODEFLIB to either avoid its costs or > not use system cache (if its uses RUNPATH). I think a system-wide tunable would > require a similar scheme, where the program can opt-out if required. Actually I was thinking of systemwide tunables as the canonical way to apply default rules that *won't* get overridden by users. That could allow users to, e.g. lock down memory tagging on a systemwide basis if needed, or put a hard upper or lower limit on some of the malloc tunables. The scheme would work similar to rlimit, but it shouldn't be misunderstood to be a security feature in that sense; applications can always work around a malloc tunable limit by rolling their own allocator. >> There's also conceivably a use case for having only systemwide tunables without any valstring override but maybe that should get supported when it's actually needed by someone.  So in summary, I'm not aware of anybody using --disable-tunables, so I'm not opposed to removing the configure flag altogether and simplifying the code.  Hopefully if someone is using it they'll come forward before this patchset gets accepted. > > Alright, so I think it should be good to setup this for next release then. Yep. I don't know how we can make this more widely visible before we drop the option. Maybe @gnutools could tweet about it. If there are no major objections in the next week or so I'll do a proper review of the patchset. Thanks, Sid