From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc32.google.com (mail-oo1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) by sourceware.org (Postfix) with ESMTPS id A8795385087A for ; Mon, 20 Mar 2023 16:59:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A8795385087A 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-oo1-xc32.google.com with SMTP id x19-20020a4a3953000000b00525191358b6so2012355oog.12 for ; Mon, 20 Mar 2023 09:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1679331562; 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=6KemMU0KnC42mLvsiE4E5Ecf4pAEN0zMQKfAg73P/+U=; b=ZmtxPwmznMd5R2oNSuM1JiyE7SB6N+N5nw5v9WcsU0/HZQ+MdNK8DHeHTOzVYks36V VJzUH34H8a/bakD0jmn3dmt2i07LUcKgX+mllPUuKd3p4PbFTiUq01XNZrOnlmGyY2wN KS8xYTDbPtdfR/Agguck5rm1OwJcHAAkJrEF52A+D2EfmeRTerU3jq14b/UDA/UrgYp9 utW8181z8GPC+uPPwwgj6L5/yfMgNrX8VmVyaz/63532Lm4h2J8ZpFyuPMEU8TKvfgGN QdSieKr2zvo/oyyrxAk20HVv2GzLhOs7ZASkw6ecpcCpXrOY3oKLw/wVSMz0GgHhRgEp Z01w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679331562; 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=6KemMU0KnC42mLvsiE4E5Ecf4pAEN0zMQKfAg73P/+U=; b=KKBhH+WwjUmka8DJ2ewhMUT3U4F0++JaPOlLMVSLYD39JBetU03ECXGE0lcRI6hRtF hILue+wXruaWYeJATRUYOM7w7QY6yc351cgNiUQ4NZhqie2r+6AEC6bNY97t51FmzYiw DdsvWh77fM/ln8YlJ2cfiAhcAWVbevLXLDhHlSsP7Mq6zBA27R9pyVeF9lXUh9W1v5Vc iW4JZ2yFzg1D5fAPmGUy3MEcANSGUiBBqpbPe/8E1OTzEWPTyE1xCapQrlZVlj5sj7eg oFUBhEwNnHDfHHXY6LMdT/LNpJvPv34jQUlpNjchSk4NG8rr/cTSMCUFPqSOOjNz1LH/ yGxw== X-Gm-Message-State: AO0yUKV48HKXIiDSzwzo1lgA4l2wXkwHnpfGCFSNAjhpqycQx3967TLb K4ObYxISCkhAWLdvLHFyboAdyIMOX19TwfYKS6apXg== X-Google-Smtp-Source: AK7set83flWAXew0u8opGOnywvwFZN+jwTKjE9B/7j7UanzZ7DZnOKQzrbKXGGQUbDlnvUneUk7Fgg== X-Received: by 2002:a4a:3710:0:b0:51a:48f4:75de with SMTP id r16-20020a4a3710000000b0051a48f475demr169693oor.0.1679331561917; Mon, 20 Mar 2023 09:59:21 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c0:c260:d4b6:6c90:6159:ac3d? ([2804:1b3:a7c0:c260:d4b6:6c90:6159:ac3d]) by smtp.gmail.com with ESMTPSA id x135-20020a4a418d000000b005382e78ae27sm3981424ooa.19.2023.03.20.09.59.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Mar 2023 09:59:21 -0700 (PDT) Message-ID: Date: Mon, 20 Mar 2023 13:59:18 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.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> <6b880467-e122-d2c5-f8d6-1394a4065753@gotplt.org> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <6b880467-e122-d2c5-f8d6-1394a4065753@gotplt.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.2 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 17/03/23 08:15, Siddhesh Poyarekar wrote: > 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. I think it might make sense for tunables that change the program semantic, such as security hardening; although I don't think it really fits for performance oriented ones (such malloc or pthread tuning). So maybe we can define a global file format where the administrator can set where setuid binaries can use it, and if uses can overwrite it. My initial idea would be something quite simple, similar to sysctl.conf: $ cat /etc/glibc-tunables.conf # tunable setuid override glibc.cpu.hwcaps=-AVX512F,-AVX2 1 0 glibc.malloc.trim_threshold=128 1 1 glibc.malloc.tcache_count=2 0 1 And I was thinking about an DF_1_NODEFLIB analogous so the program can opt-out any performance or behavior difference any tunable might incur. Although with your idea of enforceable tunable, I think it does not make much sense. > >>> 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