On Tue, 2016-09-27 at 10:13 +0200, Vlastimil Babka wrote:
> I doubt anyone runs that in production, especially if performance is of
> concern.
>
I doubt anyone serious runs select() on a large fd set in production.
Last time I used it was in last century.
On 09/27/2016 03:38 AM, Eric Dumazet wrote:
On Mon, 2016-09-26 at 17:01 -0700, Andrew Morton wrote:
I don't share Eric's concerns about performance here. If the vmalloc()
is called, we're about to write to that quite large amount of memory
which we just allocated, and the vmalloc() overhead wi
On 09/27/2016 02:01 AM, Andrew Morton wrote:
On Thu, 22 Sep 2016 18:43:59 +0200 Vlastimil Babka 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. Th
On Mon, 2016-09-26 at 17:01 -0700, Andrew Morton wrote:
> I don't share Eric's concerns about performance here. If the vmalloc()
> is called, we're about to write to that quite large amount of memory
> which we just allocated, and the vmalloc() overhead will be relatively
> low.
I did not care o
On Thu, 22 Sep 2016 18:43:59 +0200 Vlastimil Babka 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
From: Vlastimil Babka
> Sent: 26 September 2016 11:02
> On 09/23/2016 03:35 PM, David Laight wrote:
> > From: Vlastimil Babka
> >> Sent: 23 September 2016 10:59
> > ...
> >> > I suspect that fdt->max_fds is an upper bound for the highest fd the
> >> > process has open - not the RLIMIT_NOFILE value.
On 09/23/2016 03:35 PM, David Laight wrote:
From: Vlastimil Babka
Sent: 23 September 2016 10:59
...
> I suspect that fdt->max_fds is an upper bound for the highest fd the
> process has open - not the RLIMIT_NOFILE value.
I gathered that the highest fd effectively limits the number of files,
s
Eric Dumazet writes:
> On Thu, 2016-09-22 at 18:43 +0200, Vlastimil Babka 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 o
From: Vlastimil Babka
> Sent: 23 September 2016 10:59
...
> > I suspect that fdt->max_fds is an upper bound for the highest fd the
> > process has open - not the RLIMIT_NOFILE value.
>
> I gathered that the highest fd effectively limits the number of files,
> so it's the same. I might be wrong.
A
On 09/23/2016 11:42 AM, David Laight wrote:
> 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. Accordi
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 nfd
On 09/22/2016 07:07 PM, Eric Dumazet wrote:
On Thu, 2016-09-22 at 18:56 +0200, Vlastimil Babka wrote:
On 09/22/2016 06:49 PM, Eric Dumazet wrote:
> On Thu, 2016-09-22 at 18:43 +0200, Vlastimil Babka wrote:
>> The select(2) syscall performs a kmalloc(size, GFP_KERNEL) where size grows
>> with the
On Thu, 2016-09-22 at 18:56 +0200, Vlastimil Babka wrote:
> On 09/22/2016 06:49 PM, Eric Dumazet wrote:
> > On Thu, 2016-09-22 at 18:43 +0200, Vlastimil Babka wrote:
> >> The select(2) syscall performs a kmalloc(size, GFP_KERNEL) where size grows
> >> with the number of fds passed. We had a custome
On 09/22/2016 06:49 PM, Eric Dumazet wrote:
On Thu, 2016-09-22 at 18:43 +0200, Vlastimil Babka 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
On Thu, 2016-09-22 at 18:43 +0200, Vlastimil Babka 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 f
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 fallb
16 matches
Mail list logo
