[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJvTdK=VnG94ECcRVoUi8HrCbVEKc8X4_JmRTkqe+vTttf0Wsg@mail.gmail.com>
Date: Mon, 19 Apr 2021 17:33:03 -0400
From: Len Brown <lenb@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Willy Tarreau <w@....eu>, Andy Lutomirski <luto@...nel.org>,
Florian Weimer <fweimer@...hat.com>,
"Bae, Chang Seok" <chang.seok.bae@...el.com>,
Dave Hansen <dave.hansen@...el.com>, X86 ML <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>, linux-abi@...r.kernel.org,
"libc-alpha@...rceware.org" <libc-alpha@...rceware.org>,
Rich Felker <dalias@...c.org>, Kyle Huey <me@...ehuey.com>,
Keno Fischer <keno@...iacomputing.com>
Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related features
On Mon, Apr 19, 2021 at 3:15 PM Borislav Petkov <bp@...en8.de> wrote:
> 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.
For this to happen, every thread would not only have to include/link-with
code that uses AMX, but that code would have to *run*.
I'm sure that the AI guys are super excited about matrix multiplication,
but I have a hard time imagining why grep(1) would find a use for it.
Indeed, if anyone expected AMX to be used by every task, we would have
never gone to the trouble of inventing the XFD hardware to support
the kernel's lazy 8KB buffer allocation.
cheers,
Len Brown, Intel Open Source Technology Center
Powered by blists - more mailing lists