From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933412AbcI0Lkj convert rfc822-to-8bit (ORCPT ); Tue, 27 Sep 2016 07:40:39 -0400 Received: from smtp-out4.electric.net ([192.162.216.193]:50643 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933168AbcI0Lka (ORCPT ); Tue, 27 Sep 2016 07:40:30 -0400 From: David Laight To: "'Nicholas Piggin'" , Vlastimil Babka CC: Jason Baron , Hillf Danton , "'Alexander Viro'" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "'Michal Hocko'" , "netdev@vger.kernel.org" , Eric Dumazet Subject: RE: [PATCH] fs/select: add vmalloc fallback for select(2) Thread-Topic: [PATCH] fs/select: add vmalloc fallback for select(2) Thread-Index: AQHSGLFrj/X++D4HnkmfrbWt9vaWXaCNM7bQ Date: Tue, 27 Sep 2016 11:37:24 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DB010A97D@AcuExch.aculab.com> References: <20160922152831.24165-1-vbabka@suse.cz> <006101d21565$b60a8a70$221f9f50$@alibaba-inc.com> <20160923172434.7ad8f2e0@roar.ozlabs.ibm.com> <57E55CBB.5060309@akamai.com> <5014387d-43da-03f6-a74b-2dc4fbf4fe32@suse.cz> <20160927212458.3ab42b41@roar.ozlabs.ibm.com> In-Reply-To: <20160927212458.3ab42b41@roar.ozlabs.ibm.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuExch.aculab.com X-TLS: TLSv1:AES128-SHA:128 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Nicholas Piggin > Sent: 27 September 2016 12:25 > On Tue, 27 Sep 2016 10:44:04 +0200 > Vlastimil Babka 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" 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 :) If they care about performance they shouldn't be passing select() lists that are anywhere near that large. If the number of actual fd is small - use poll(). Otherwise you want one of the 'event' mechanisms in order to avoid setting the markers on every fd after every event (can't remember how you do that in Linux). At least this isn't SYSV - poll() was O(n^2) in the number of fd (because the fd were on a linked list). David