From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) by sourceware.org (Postfix) with ESMTPS id 100753858C83 for ; Wed, 15 Mar 2023 20:05:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 100753858C83 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-ot1-x32a.google.com with SMTP id v2-20020a056830090200b0069c6952f4d3so228095ott.7 for ; Wed, 15 Mar 2023 13:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1678910727; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=OGttKKZZSFwuubz1fPnehDN1oAVHfd5BoP/5aJyCXZ0=; b=Cpg+CHb6/pi4D6iMU6jNBJUKOcWRGVRkbRe3MYeJCYCU7oAbervNRxO0Id/7tLFjmd ZFLlV9SX8VIa9VUBMVvv4cCGqdF6HE4ETK0llgexQfivWXOsYcIE54AWXL5KjEortvfB 69o2OhaFaoWfA4qZ96QRwm7dnlNKYvxTMnnpx6HaxZcahap5Zkqi0y6hTzWs/E2s6TJi 5IGJhqtvc/XUzFDQXTK46BshgcMbCRNfY95aTS1lh7VZyNF2uafvTUQV1hgwF7iKPQsD fuC/EHyaXpW6Jd3PByG+g8p6oEfd/vyTAJTg3H9bsejtsI77x57PZw1C5YznJiySqSDb rmrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678910727; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=OGttKKZZSFwuubz1fPnehDN1oAVHfd5BoP/5aJyCXZ0=; b=vUmmdPKTzHVz/Yc5MAthPXM1ANaXCpWM2DWcrS50jLv9Arv1WCuEiFJzRVFHoZkU3A bILSj6Uo0bPN/9dNX3TJ3j0bv/QzX+h9lXevzPmUkbooiNaSAjJ3Vzbof5DVMKrADuXx XUydhDRPrJDIesbZ1UGMPEd0O7kVSTPmDQSJLBFDT6+J/40aIwmxVkM/F1wtExjXNtG5 uEWp/AoqwlL6VAJYvp+76deiB/tmP/MN6u/XGTjjy0wTWJkldMZoA3KOVIYTDdbZlA18 OWC9E4L0/0S1dgCjtij5Vjvsy5mCkglZt6+cn0djuA0EwoT7BkmQEDm6X/AvYL50rBYU ht0w== X-Gm-Message-State: AO0yUKWckUby36Rq7tVNNYwF5FVsiNxHbeUazPRhJlDmjyo1gIn6LfFx 22oXbsCAd4Lva7uRYrX8h5+p50QRwVEgQtiXjuHluw== X-Google-Smtp-Source: AK7set+xgjUV2E4yDLXgRH/UmU9Ogqa9erD62GhZu8lyCqjnUyaqZryeEAnLBd9emat6Xcgtxmi10A== X-Received: by 2002:a9d:3b3:0:b0:69b:ce73:4942 with SMTP id f48-20020a9d03b3000000b0069bce734942mr884354otf.31.1678910727204; Wed, 15 Mar 2023 13:05:27 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c0:544b:8d01:8008:2c0e:dce7? ([2804:1b3:a7c0:544b:8d01:8008:2c0e:dce7]) by smtp.gmail.com with ESMTPSA id f93-20020a9d2c66000000b00697be532609sm2084235otb.73.2023.03.15.13.05.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Mar 2023 13:05:26 -0700 (PDT) Message-ID: Date: Wed, 15 Mar 2023 17:05:24 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH 0/2] Make tunable a default feature Content-Language: en-US To: Siddhesh Poyarekar , libc-alpha@sourceware.org, Florian Weimer References: <20230313190627.2000578-1-adhemerval.zanella@linaro.org> <6511a415-b165-586d-b22d-80ff4eef0fa8@gotplt.org> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <6511a415-b165-586d-b22d-80ff4eef0fa8@gotplt.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,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 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. > > 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. > > 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.