On Tue, 27 Sep 2016 10:44:04 +0200 Vlastimil Babka <vbabka@xxxxxxx> wrote: > On 09/23/2016 06:47 PM, Jason Baron wrote: > > Hi, > > > > On 09/23/2016 03:24 AM, Nicholas Piggin wrote: > >> On Fri, 23 Sep 2016 14:42:53 +0800 > >> "Hillf Danton" <hillf.zj@xxxxxxxxxxxxxxx> wrote: > >> > >>>> > >>>> 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 from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
