On 10/13/20 3:31 PM, Brown, Len wrote: > vmalloc() does not fail, and does not return an error, and so there is no > concept > of returning a signal.
Well, the order-0 allocations are no-fail, as are the vmalloc kernel structures and the page tables that might have to be allocated. But, that's not guaranteed to be in place *forever*. I think we still need to check for and handle allocation failures, even if they're not known to be possible today. > If we got to the point where vmalloc() sleeps, then the system > has bigger OOM issues, and the OOM killer would be on the prowl. vmalloc() can *certainly* sleep. Allocation failures mean returning NULL from the allocator, and the very way we avoid doing that is by sleeping to go reclaim some memory from some other allocation. Sleeping is a normal and healthy part of handling allocation requests, including vmalloc(). > If we were concerned about using vmalloc for a couple of pages in the task > structure, > Then we could implement a routine to harvest unused buffers and free them -- > but that didn't seem worth the complexity. Note that this feature is 64-bit > only. IMNHO, vmalloc() is overkill for ~10k, which is roughly the size of the XSAVE buffer for the first AMX implementation. But, it's not overkill for the ~66k of space that will be needed if some CPU implementation comes along and uses all of the architectural space AMX provides.
