[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJvTdKm=mPQUhJax-UietFFELOuHn89he6FPNb5jUC_Mcdc_rw@mail.gmail.com>
Date: Tue, 31 Aug 2021 18:07:23 -0400
From: Len Brown <lenb@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: "Chang S. Bae" <chang.seok.bae@...el.com>,
Andy Lutomirski <luto@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>, X86 ML <x86@...nel.org>,
"Brown, Len" <len.brown@...el.com>,
Dave Hansen <dave.hansen@...el.com>,
Thiago Macieira <thiago.macieira@...el.com>,
"Liu, Jing2" <jing2.liu@...el.com>,
"Ravi V. Shankar" <ravi.v.shankar@...el.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v9 12/26] x86/fpu/xstate: Use feature disable (XFD) to
protect dynamic user state
On Mon, Aug 30, 2021 at 1:52 PM Borislav Petkov <bp@...en8.de> wrote:
> Well, if you preallocate everything...
Nothing prevents, say, a pthread_create() or anything
else where the kernel consumes memory on behalf of a process
from failing at run-time... AMX does not add a unique OOM risk here.
> > The advantage of the #NM over the syscall is that the programmer
> > doesn't actually have to do anything. Also, transparently allocated
> > buffers offer a theoretical benefit that a program may have many
> > threads, but only a few may actually touch AMX, and so there is
> > savings to be had by allocating buffers only for the threads that
> > actually use the buffers.
>
> The program already asked the kernel whether it can use AMX - it can
> allocate the buffers for the threads too.
The result is that if one thread in a 1,000 task process requests
and touches AMX, the kernel would allocate 8MB, instead of 8KB
of context switch buffers for that process, no?
Len Brown, Intel Open Source Technology Center
Powered by blists - more mailing lists