On Tue, 27 Sep 2016 10:44:04 +0200
Vlastimil Babka [off-list ref] wrote:

On 09/23/2016 06:47 PM, Jason Baron wrote:

quoted

Hi,

On 09/23/2016 03:24 AM, Nicholas Piggin wrote:  

quoted

On Fri, 23 Sep 2016 14:42:53 +0800
"Hillf Danton" [off-list ref] wrote:
 

quoted

quoted

The select(2) syscall performs a kmalloc(size, GFP_KERNEL) where size grows
with the number of fds passed. We had a customer report page allocation
failures of order-4 for this allocation. This is a costly order, so it might
easily fail, as the VM expects such allocation to have a lower-order fallback.

Such trivial fallback is vmalloc(), as the memory doesn't have to be
physically contiguous. Also the allocation is temporary for the duration of the
syscall, so it's unlikely to stress vmalloc too much.

Note that the poll(2) syscall seems to use a linked list of order-0 pages, so
it doesn't need this kind of fallback.  

How about something like this? (untested)  

This pushes the limit further, but might just delay the problem. Could be an 
optimization on top if there's enough interest, though.

What's your customer doing with those selects? If they care at all about
performance, I doubt they want select to attempt order-4 allocations, fail,
then use vmalloc :)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>