From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id F342438708D2 for ; Fri, 31 May 2024 20:24:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F342438708D2 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F342438708D2 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717187080; cv=none; b=mul/rH0jkuU7K3CB+B9GDJ4yvN4mmTRUh9tzgeoG6mwcayFaaUivxM2gFNWm40WSdi3USx1sEI8lwR4rU7k+1p7FozSdU4r8Z+K4DQZGX+YVgnJqqtj/VjuRIDKiiGyatyBkxt9ZFPoy6kxVSsSiYejbclCYVKKFAf605CZxtJs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717187080; c=relaxed/simple; bh=wsFNs0YTBcNEmrY7YXZUj6t+h2xwlsdqkpo4NmaeD3s=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=cCK+JAllzxfAnyvbGGgwQJvTvdSPlBVGfi2Rbbbz940ZK0pc3nniIr9RdBkzBkgejkcQVEKhFFS1iqMBxImCpqd07XiWdEcTiBnU/oqH9qDorR7W/SNeFUFRFLK+D/2SxNO0xoUq3ZTM3p/GPgEpoT1FNcKKPZOkcbIXIJvy79A= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1717187078; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=bsyw7CVN/u7qFWcGd414NeQ+aRZ01vYQakKTePJKq/0=; b=AcvI6GV/yI1Ii+lRWeAtuV18TEeDFKOeYKBPZ16qyE5iZv+/7JnhbJsBU5LibCVT7jPDI8 nkEbphNTon0APSSPX6ttMgRD5D+qruiOprxRpf4xFGjXTsrQP37xXnB6Ik/6T088Qs3hGQ MGUCZcGeqyQdLEypyEqbug5zrq/oMpI= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-556-VrAhuumSPYe9NGn-NmuowQ-1; Fri, 31 May 2024 16:24:32 -0400 X-MC-Unique: VrAhuumSPYe9NGn-NmuowQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9C62E85A58C; Fri, 31 May 2024 20:24:32 +0000 (UTC) Received: from greed.delorie.com (unknown [10.22.9.56]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7CB952026D6E; Fri, 31 May 2024 20:24:32 +0000 (UTC) Received: from greed.delorie.com.redhat.com (localhost [127.0.0.1]) by greed.delorie.com (8.16.1/8.16.1) with ESMTP id 44VKOQGl4117989; Fri, 31 May 2024 16:24:26 -0400 From: DJ Delorie To: Adhemerval Zanella Netto Cc: szabolcs.nagy@arm.com, libc-alpha@sourceware.org Subject: Re: [PATCH v2 0/3] System-wide tunables In-Reply-To: <10c931d2-607f-4986-a7d6-1e821fe85b11@linaro.org> (message from Adhemerval Zanella Netto on Tue, 28 May 2024 16:18:40 -0300) Date: Fri, 31 May 2024 16:24:26 -0400 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: Adhemerval Zanella Netto writes: > I think it makes sense to add arch-specific tunables on same system, > even though this kind of deployment in not that usual as before (maybe > on some debian-like system with qemu-user). Would it make sense to add per-arch filters to the tunables themselves? So that setting a tunable via GLIBC_TUNABLES can be arch-specific as well? I.e. GLIBC_TUNABLES=glibc.malloc.check@x86-64=3 with other punctuation adding other filters, like !progname or :uid ld.so.cache uses the file itself as an arch filter, there's nothing in the cache that indicates arch (just hwcaps and abi), so using the name itself as an arch filter would be consistent. > The dl-tunable-list.h is already arch-specific, meaning that the > environment parsing code will ignore unknown/invalid tunable. So > for system-wide configuration, I would expect that ldconfig to ignore > such entries (possible with an warning) and only add on the cache > valid tunables. Currently it stores them as-is, but without a valid tunable ID. That forces the program to re-parse the tunable, so that the cache and the program need not be in sync.