On Thu, May 20, 2021 at 5:13 PM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > >> Regarding error return for allocation failures. ... > * vmalloc() can fail (the memory.kmem cgroup limit is probably the most > likely place to be exposed to this) > * vmalloc() failure in a fault (like #NM) will result in SIGSEGV > * vmalloc() failure in a syscall can be handled with -ENOMEM Thanks for clarifying this, Dave. We added the explicit-allocate to v5, which should be on the list by tomorrow. So the questions are: 1. who calls it -- a call/thread or process? the application? a library -- which library? 2. is it optional, or mandatory? 3. if it is mandatory, what is the best way to enforce it? 4. should we have a "release" system call too? 1. Every thread needs a context switch buffer. Does every thread make the system call? It seems sort of awkward for a library to always make a system call before doing a TMUL. It would be functionally harmless, but it would add latency to an otherwise low-latency operation. If some central library does it, and caches that it has done it before, then it would be ugly, but at least it would remove an unnecessary user/kernel transition. 2. If it is optional, then v5 is code complete -- because it allows you to allocate either explicitly via prtcl, or transparently via #NM. 3. If it is mandatory, then we should re-purpose the XFD mechanism: app starts with XFD armed, by default if app touches AMX before prctl, it takes a signal (and dies). When app calls prctl, allocate buffer disarm XFD for that app (exactly what #NM trap does today). 4. I don't see a justification for a release concept, but it is possible -- though sort of sticky with possible nested calls from combinations of apps and libraries. If that were sorted out by a central library, then the actual system call on the last release per thread would re-arm XFD to prevent access until the next explicit request. Unclear if it is important that the kernel actually do the free -- some things might run faster if we keep it around... Len Brown, Intel Open Source Technology Center
