From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758739AbcIWJp1 (ORCPT ); Fri, 23 Sep 2016 05:45:27 -0400 Received: from smtp-out6.electric.net ([192.162.217.190]:59860 "EHLO smtp-out6.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757333AbcIWJpM (ORCPT ); Fri, 23 Sep 2016 05:45:12 -0400 From: David Laight To: "'Vlastimil Babka'" , Eric Dumazet CC: Alexander Viro , Andrew Morton , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Michal Hocko , "netdev@vger.kernel.org" , Linux API , "linux-man@vger.kernel.org" Subject: RE: [PATCH v2] fs/select: add vmalloc fallback for select(2) Thread-Topic: [PATCH v2] fs/select: add vmalloc fallback for select(2) Thread-Index: AQHSFPtnA7bZnB3Yc0m96JsM2uwSuaCG0LqA Date: Fri, 23 Sep 2016 09:42:07 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DB0107DC8@AcuExch.aculab.com> References: <20160922164359.9035-1-vbabka@suse.cz> <1474562982.23058.140.camel@edumazet-glaptop3.roam.corp.google.com> <12efc491-a0e7-1012-5a8b-6d3533c720db@suse.cz> <1474564068.23058.144.camel@edumazet-glaptop3.roam.corp.google.com> In-Reply-To: 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="utf-8" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u8N9jWBH023102 From: Vlastimil Babka > Sent: 22 September 2016 18:55 ... > So in the case of select() it seems like the memory we need 6 bits per file > descriptor, multiplied by the highest possible file descriptor (nfds) as passed > to the syscall. According to the man page of select: > > EINVAL nfds is negative or exceeds the RLIMIT_NOFILE resource limit (see > getrlimit(2)). That second clause is relatively recent. > The code actually seems to silently cap the value instead of returning EINVAL > though? (IIUC): > > /* max_fds can increase, so grab it once to avoid race */ > rcu_read_lock(); > fdt = files_fdtable(current->files); > max_fds = fdt->max_fds; > rcu_read_unlock(); > if (n > max_fds) > n = max_fds; > > The default for this cap seems to be 1024 where I checked (again, IIUC, it's > what ulimit -n returns?). I wasn't able to change it to more than 2048, which > makes the bitmaps still below PAGE_SIZE. > > So if I get that right, the system admin would have to allow really large > RLIMIT_NOFILE to even make vmalloc() possible here. So I don't see it as a large > concern? 4k open files isn't that many. Especially for programs that are using pipes to emulate windows events. I suspect that fdt->max_fds is an upper bound for the highest fd the process has open - not the RLIMIT_NOFILE value. select() shouldn't be silently ignoring large values of 'n' unless the fd_set bits are zero. Of course, select does scale well for high numbered fds and neither poll nor select scale well for large numbers of fds. David