From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by sourceware.org (Postfix) with ESMTPS id 05633396B439 for ; Mon, 19 Apr 2021 19:15:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 05633396B439 Received: from zn.tnic (p200300ec2f07810057dd6a0ceac1c230.dip0.t-ipconnect.de [IPv6:2003:ec:2f07:8100:57dd:6a0c:eac1:c230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id DAFDC1EC0493; Mon, 19 Apr 2021 21:15:42 +0200 (CEST) Date: Mon, 19 Apr 2021 21:15:39 +0200 From: Borislav Petkov To: Len Brown Cc: Willy Tarreau , Andy Lutomirski , Florian Weimer , "Bae, Chang Seok" , Dave Hansen , X86 ML , LKML , linux-abi@vger.kernel.org, "libc-alpha@sourceware.org" , Rich Felker , Kyle Huey , Keno Fischer Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related features Message-ID: <20210419191539.GH9093@zn.tnic> References: <20210413034346.GA22861@1wt.eu> <20210414095804.GB10709@zn.tnic> <20210415044258.GA6318@zn.tnic> <20210415052938.GA2325@1wt.eu> <20210415054713.GB6318@zn.tnic> <20210419141454.GE9093@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: Mon, 19 Apr 2021 19:15:47 -0000 On Mon, Apr 19, 2021 at 02:18:51PM -0400, Len Brown wrote: > Yes, we could invent a new system call and mandate that it be called > between #2 and #3. However, we'd still do #4 in response, so I don't > see any value to that system call. Lemme refresh your memory: there was a time when the kernel did lazy FPU switching because tasks which really wanted to do that, would use FPU insns and from the first use onwards, the kernel would shuffle an FPU state buffer back'n'forth for the task, for the length of its lifetime. Then glibc decided to use FPU in memcpy or whatever, leading up to *every* task using the FPU which practically made us remove all that lazy FPU switching logic and do eager FPU. Back then that state was what, dunno, 1-2 KB tops. Now imagine the same lazy => eager switch but with AVX or AMX or . All of a sudden you have *every* thread sporting a fat 8K buffer because the library decided to use a fat buffer feature for it. Nope, I don't want that to happen. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette