From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from desiato.infradead.org (desiato.infradead.org [IPv6:2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by sourceware.org (Postfix) with ESMTPS id 5081A38515F4 for ; Mon, 28 Jun 2021 13:21:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5081A38515F4 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=tETVd4qfZs7ZyGjHOxKkFCYCB/FaFBzlz/HaF4lqmR8=; b=m+9V3FPa/m6WA3KarpSESel7V5 F2SVzBINIxzlN0tdjV5WAFh1r6Rd/sWy9bVKMxOA8i3pl7PHSJS2cNgvTa6F3RAdTFOclcW4GeJBm qC2UswMQeO9cB/MlxC9Eeu1Ubk6qr1i3QB7/QivQsfFU3DZA8h/qHaKpjrSUocCNcmGGIcWPgWXis l1PBWmSdKvKve9mrKoRgzbj2LXP7ohe52DZu0zyvrAWPoutX0X5otnqcZ7RKiu0xWv2r61WbqkwvE 8ulItWULPYD5y/ZnBAOYuqXLZMksSZnWeWRo5V320CTNB3rRzp24x/wa7b/M0ozEIWQeKnE879s3C pwDCYQOw==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1lxrBx-00CZ9E-68; Mon, 28 Jun 2021 13:20:49 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 2E82F300242; Mon, 28 Jun 2021 15:20:48 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 0F0E320157117; Mon, 28 Jun 2021 15:20:48 +0200 (CEST) Date: Mon, 28 Jun 2021 15:20:48 +0200 From: Peter Zijlstra To: "Enrico Weigelt, metux IT consult" Cc: Thiago Macieira , fweimer@redhat.com, hjl.tools@gmail.com, libc-alpha@sourceware.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, x86@kernel.org Subject: Re: x86 CPU features detection for applications (and AMX) Message-ID: References: <22261946.eFiGugXE7Z@tjmaciei-mobl1> <3c5c29e2-1b52-3576-eda2-018fb1e58ff9@metux.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3c5c29e2-1b52-3576-eda2-018fb1e58ff9@metux.net> X-Spam-Status: No, score=1.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_ABUSEAT, RCVD_IN_DNSWL_NONE, RCVD_IN_SBL_CSS, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: * 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: Mon, 28 Jun 2021 13:21:06 -0000 On Mon, Jun 28, 2021 at 02:40:32PM +0200, Enrico Weigelt, metux IT consult wrote: > Going back to AMX - just had a quick look at the spec (*1). Sorry, but > this thing is really weird and horrible to use. Come on, these chips > already have billions of transistors, it really can't hurt so much > spending a few more to provide a clean and easy to use machine code > interface. Grmmpf! (This is a general problem we've got with so many > HW folks, why can't them just talk to us SW folks first so we can find > a good solution for both sides, before that goes into the field ?) > > And one point that immediately jumps into my mind (w/o looking deeper > into it): it introduces completely new registers - do we now need extra > code for tasks switching etc ? No, but because it's register state and part of XSAVE, it has immediate impact in ABI. In particular, the signal stack layout includes XSAVE (as does ptrace()). At the same time, 'legacy' applications (up until _very_ recently) had a minimum signal stack size of 2K, which is already violated by the addition of AVX512 (there's actual breakage due to that). Adding the insane AMX state (8k+) into that is a complete trainwreck waiting to happen. Not to mention that having !INIT AMX state has direct consequences for P-state selection and thus performance. For these reasons, us OS folks, will mandate you get to do a prctl() to request/release AMX (and we get to say: no). If you use AMX without this, the instruction will fault (because not set in XCR0) and we'll SIGBUS or something. Userspace will have to do something like: - check CPUID, if !AMX -> fail - issue prctl(), if error -> fail - issue XGETBV and check the AMX bit it set, if not -> fail - request the signal stack size / spawn threads - use AMX Spawning threads prior to enabling AMX will result in using the wrong signal stack size and result in malfunction, you get to keep the pieces.