Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp2590687pxb; Mon, 19 Apr 2021 09:05:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz3OjcmvK3/HlMg+SgIsaRZ5tv2AAEHnc4NPGniZjZA1iAqo01eikxnWIpN79dtEesd2ZVL X-Received: by 2002:a05:6402:34cd:: with SMTP id w13mr26794879edc.73.1618848324870; Mon, 19 Apr 2021 09:05:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618848324; cv=none; d=google.com; s=arc-20160816; b=b6AyNezbLL5+e3x2bEsPP9gd1zwxsgPFrLfgCNK8X6G9KGg0p1P4J0krdtk0uMtQNz uoFPIaM/xfdsxLfsHm/FeeMVeFqd1UBj91OTsTuWozepHONbhRRji6KtAZGJSGXt9f1D n/9W29eCH4UraHiyA09bvvbrVzgoAWocVRBhJzjLlvKoYfsaCf7bJ9OFE7JrhXI6yS6P WKmeFfIUqMCi/7iijo9zvbeAWqO4IVd2quIw53SM3XMv4SmRUpy1VxZ3x4DudSLy3E6u 8lYSujnwZoIUWKFuYCg8jlJO3pNKMqx7h3AcOdxOeWaq7QQCE4rs9KEc04/IQRm/HHDj q2Yw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=xYer5YJmlFMgyX1gFaAIU9JdbMZm0L97+s4VR7XbJfA=; b=zsNM675fX5rAU4I5JPBx/OuOfgp7Z6vvxUJQXatjA6GetbKVuN+yrPrOYWOiDB5mel m3ClYAG8A5WrABYfNNl5OA9T4VOvp2O2/P0GBDi3g2Nk9okY6PBmUUHrQ7XAJDiZZHQq 1QMD2sqSsxfZhR8dYbFlJFolB+ea94UkuLR8yfaWobY4Eu8kxhl+POHQCOyPuDT6rX5g yMDvw/1fSKJFkDg2djSA+DAzD6tYi425KOUgFfVU5zESzNukbI1TeAHa4o8w7XWbmDgM C7hg0vzhG07jR42oNUllOhSbPsPqMN380XrVsH6Ka7WcAter45lczToLUxAhR5fNaqRF 7nkA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=C1Qht14q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t22si12261897ejj.746.2021.04.19.09.05.00; Mon, 19 Apr 2021 09:05:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=C1Qht14q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238360AbhDSOPa (ORCPT + 99 others); Mon, 19 Apr 2021 10:15:30 -0400 Received: from mail.skyhub.de ([5.9.137.197]:53770 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237765AbhDSOP3 (ORCPT ); Mon, 19 Apr 2021 10:15:29 -0400 Received: from zn.tnic (p200300ec2f078100afa224062884c679.dip0.t-ipconnect.de [IPv6:2003:ec:2f07:8100:afa2:2406:2884:c679]) (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 908A91EC03A0; Mon, 19 Apr 2021 16:14:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1618841698; 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: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=xYer5YJmlFMgyX1gFaAIU9JdbMZm0L97+s4VR7XbJfA=; b=C1Qht14qU6fl4YF08sxDKkyN12IL2huAGrGrdEwzWJ3MokzicBoijBRQgqYtQw36Qckuqd Nz+JV3yiF6celQeYJfOk+EbbOT7sqYBLa3CyBDv7V3E7wk7rSnVQUyELLWRjZNeDyYsOrM O7xg+U3yeltDHb/s2XhkH4yTneYxqOQ= Date: Mon, 19 Apr 2021 16:14:54 +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: <20210419141454.GE9093@zn.tnic> References: <20210413034346.GA22861@1wt.eu> <20210414095804.GB10709@zn.tnic> <20210415044258.GA6318@zn.tnic> <20210415052938.GA2325@1wt.eu> <20210415054713.GB6318@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 16, 2021 at 06:05:10PM -0400, Len Brown wrote: > I'm not aware of any intent to transparently use AMX for bcopy, like > what happened > with AVX-512. (didn't they undo that mistake?) No clue, did they? > Tasks are created without an 8KB AMX buffer. > Tasks have to actually touch the AMX TILE registers for us to allocate > one for them. When tasks do that it doesn't matter too much - for the library it does! If the library does that by default and the processes which comprise of that pipe I mentioned earlier, get all 8K buffers because the underlying library decided so and swinging those buffers around when saving/restoring contexts turns out to be a performance penalty, then we have lost. Lost because if that thing goes upstream in this way of use of AMX is allowed implicitly, there ain't fixing it anymore once it becomes an ABI. So, that library should ask the kernel whether it supports AMX and only use it if has gotten a positive answer. And by default that answer should be "no" because the majority of processes - that same pipe I keep mentioning - don't need it. I have no good idea yet how granulary that should be - per process, per thread, whatever, but there should be a way for the kernel to control whether the library uses AMX, AVX512 or whatever fat state is out there available. Then, if a process wants the library to use AMX on its behalf, then it can say so and the library can do that but only after having asked for explicitly. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette