From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <tglx@linutronix.de>
Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55])
 by sourceware.org (Postfix) with ESMTPS id B0CFB3853834
 for <libc-alpha@sourceware.org>; Fri,  7 May 2021 18:44:04 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B0CFB3853834
From: Thomas Gleixner <tglx@linutronix.de>
To: Dave Hansen <dave.hansen@intel.com>, Florian Weimer <fweimer@redhat.com>,
 Len Brown <lenb@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>, Willy Tarreau <w@1wt.eu>,
 Andy Lutomirski <luto@kernel.org>, "Bae\,
 Chang Seok" <chang.seok.bae@intel.com>, X86 ML <x86@kernel.org>,
 LKML <linux-kernel@vger.kernel.org>, linux-abi@vger.kernel.org,
 "libc-alpha\@sourceware.org" <libc-alpha@sourceware.org>,
 Rich Felker <dalias@libc.org>, Kyle Huey <me@kylehuey.com>,
 Keno Fischer <keno@juliacomputing.com>
Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related
 features
In-Reply-To: <5d3d513b-77d6-e2e2-779e-ff3ea33deba3@intel.com>
References: <20210415044258.GA6318@zn.tnic> <20210415052938.GA2325@1wt.eu>
 <20210415054713.GB6318@zn.tnic>
 <CAJvTdKnjzAMh3N_c7KP3kA=e0LgYHgCANg44oJp3LcSm7dtbSQ@mail.gmail.com>
 <20210419141454.GE9093@zn.tnic>
 <CAJvTdK=p8mgO3xw9sRxu0c7NTNTG109M442b3UZh8TqLLfkC1Q@mail.gmail.com>
 <20210419191539.GH9093@zn.tnic>
 <CAJvTdK=VnG94ECcRVoUi8HrCbVEKc8X4_JmRTkqe+vTttf0Wsg@mail.gmail.com>
 <20210419215809.GJ9093@zn.tnic>
 <CAJvTdKn6JHo02karEs0e5g+6SimS5VUcXKjCkX35WY+xkgAgxw@mail.gmail.com>
 <YIMmwhEr46VPAZa4@zn.tnic>
 <CAJvTdKnhXnynybS4eNEF_EtF26auyb-mhKLNd1D9_zvCrchZsw@mail.gmail.com>
 <87bl9s8kfb.fsf@oldenburg.str.redhat.com>
 <5d3d513b-77d6-e2e2-779e-ff3ea33deba3@intel.com>
Date: Fri, 07 May 2021 20:44:02 +0200
Message-ID: <87o8dmmljh.ffs@nanos.tec.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-2.2 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 <libc-alpha.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Fri, 07 May 2021 18:44:05 -0000

On Mon, May 03 2021 at 06:43, Dave Hansen wrote:
> On 5/2/21 10:18 PM, Florian Weimer wrote:
>>> 5. If the feature is enabled in XCR0, the user happily uses it.
>>>
>>>     For AMX, Linux implements "transparent first use"
>>>     so that it doesn't have to allocate 8KB context switch
>>>     buffers for tasks that don't actually use AMX.
>>>     It does this by arming XFD for all tasks, and taking a #NM
>>>     to allocate a context switch buffer only for those tasks
>>>     that actually execute AMX instructions.
>> What happens if the kernel cannot allocate that additional context
>> switch buffer?
>
> Well, it's vmalloc()'d and currently smaller that the kernel stack,
> which is also vmalloc()'d.  While it can theoretically fail, if it
> happens you have bigger problems on your hands.

Such a buffer allocation might also exceed a per process/cgroup
limitation. Anything else which is accounted happens in syscall context
which then returns an error on which the application can react.

So what's the consequence when the allocation fails? Kill it right away
from #NM? Kill it on the first signal? Do nothing and see what happens?

Thanks,

        tglx