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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id A9F1B3857C73 for ; Fri, 19 Mar 2021 21:12:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A9F1B3857C73 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-45-FwSzf48HMvOvIEIZvmgbQw-1; Fri, 19 Mar 2021 17:12:36 -0400 X-MC-Unique: FwSzf48HMvOvIEIZvmgbQw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 429F910082E0; Fri, 19 Mar 2021 21:12:35 +0000 (UTC) Received: from rhel8.vm.delorie.com (ovpn-115-112.rdu2.redhat.com [10.10.115.112]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 12B1D5C1BB; Fri, 19 Mar 2021 21:12:34 +0000 (UTC) Received: from rhel8.vm.redhat.com (localhost [127.0.0.1]) by rhel8.vm.delorie.com (8.15.2/8.15.2) with ESMTPS id 12JLCXSG225456 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 19 Mar 2021 17:12:33 -0400 From: DJ Delorie To: Szabolcs Nagy Cc: libc-alpha@sourceware.org Subject: Re: tunables vs osxsave vs checkpointing vs _dl_runtime_resolve In-Reply-To: <20210319164334.GA3876@arm.com> (message from Szabolcs Nagy on Fri, 19 Mar 2021 16:43:35 +0000) Date: Fri, 19 Mar 2021 17:12:33 -0400 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 21:12:39 -0000 Szabolcs Nagy writes: > so are we supposed to handle migrations to machines with > different arch extensions? No, that's not the intent. There's a lot of "caveat user" in what our customer wants, and if the x86 tunables didn't already *almost* do what they wanted, we would have just said no. I mean, x86 has code to do what our customer wants, and has code to let tunables control it, it just didn't actually work. So in this case, it's more of a bug fix than a new feature. > cpu_features based decisions can break across different > machines and there is no reliable (future proof) way to > request baseline arch features. That's a separate problem, which we've solved with ifuncs, but others solve with multilibs. X86 chooses to let tunables override ifunc choices, and exposes CPU features, setting an expectation. If other arches don't do that, so be it.