On Mon, Aug 30, 2021 at 2:04 PM Dave Hansen [off-list ref] wrote:

On 8/24/21 4:17 PM, Len Brown wrote:

quoted

Even if your AMX thread pool threads were to invoke this system call
as soon as possible...
What is to say that the thread pool is created only at a time when memory
is available?  A thread could be created 24 hours into program execution
under OOM conditions and this system call will return ENOMEM, and your program
will in all likelihood throw up its arms and exit at the exact same place
it would exit for transparently allocated buffers.

I tried this exact line of reasoning with Thomas: it doesn't matter
where we run out of memory, we still need the same memory and we're
screwed either way.

However, Thomas expressed a clear preference for ABIs which return
memory failures explicitly at syscalls versus implicit failures which
can happen on random instructions.

One might say that the odds of checking for and handling a NULL value
(or ENOMEM) are the same as installing a signal handler.  *But*, it's
infinitely easier to unroll state and recover from a NULL than it is to
handle it from within a signal handler.  In other words, the explicit
ones *encourage* better programming.

I agree.
Indeed, I believe that there is universal agreement that a synchronous
return code
from a system call is a far superior programming model than decoding
the location of a failure in a system call.  (no, the IP isn't random -- it is
always the 1st instruction in that thread to touch a TMM register).

I'd prefer removing the demand-driven allocation at this point.

Adding a pre-allocate system call that can gracefully fail
(even though it never will) is independent from removing
demand-driver allocation.  I would leave this to application
developers.  Honestly, the kernel shouldn't care.

-- 
Len Brown, Intel Open Source Technology Center