public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <dada1@cosmosbay.com>
To: Valdis.Kletnieks@vt.edu
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] get rid of NR_OPEN and introduce a sysctl_nr_open
Date: Tue, 27 Nov 2007 08:58:06 +0100	[thread overview]
Message-ID: <474BCE0E.4090900@cosmosbay.com> (raw)
In-Reply-To: <4651.1196148356@turing-police.cc.vt.edu>

Valdis.Kletnieks@vt.edu a écrit :
> On Tue, 27 Nov 2007 08:09:19 +0100, Eric Dumazet said:
> 
>> Changing NR_OPEN is not considered safe because of vmalloc space potential 
>> exhaust.
> 
> Verbiage about this point...
> 
> 
>> +nr_open
>> +-------
>> +
>> +Denotes the maximum number of file-handles a process can
>> +allocate. Default value is 1024*1024 (1048576) which should be
>> +enough for most machines. Actual limit depends on RLIMIT_NOFILE
>> +resource limit.
>> +
> 
> should probably be in here - can you add something of the form "Setting this
> too high can cause vmalloc failures, especially on smaller-RAM machines",
> and/or *say* how much RAM the default takes?  Sure, it's 1M entries, but
> my tuning on a 2G-RAM machine will differ if these are byte-sized, or 128-byte
> sized - one is off in a corner, the other is 1/16th of my entire memory.

vmalloc failures can already happen if you start 32 processes on i386 kernels, 
each of them wanting to open file handle number 600.000 (if their 
RLIMIT_NOFILE >= 600000)

fcntl(0, F_DUPFD, 600000);

We are not going to add warnings about vmalloc on every sysctl around there 
that could allow a root user to exhaust vmalloc space. This is a vmalloc issue 
on 32bit kernel, and quite frankly I never hit this limit.

If you take a look at vmalloc() implementation, fact that it uses a 'struct 
vm_struct *vmlist;' to track all active zones show that vmalloc() is not used 
that much.

> 
> Also, would it be useful to *lower* the value drastically, if you know a priori
> that no process should get up to 1K file handles, much less 1M? Does that
> buy me anything different than setting RLIMIT_NOFILE=1024?

NR_OPEN is the max value that RLIMIT_NOFILE can reach, nothing more.

You can set it to 256*1024*1024 or 4*1024 it wont change memory needs on your 
machine, unless you raise RLIMIT_NOFILE and one of your program leaks file 
handles, or really want to open simultaneously many of them.

Most programs wont open more than 500 files, so their file table is allocated 
via kmalloc()


  reply	other threads:[~2007-11-27  7:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200711200023.lAK0NtEe004292@imap1.linux-foundation.org>
     [not found] ` <20071120004832.393cc5a8@the-village.bc.nu>
     [not found]   ` <474291E7.5060700@cosmosbay.com>
     [not found]     ` <20071120001411.4db1eb04.akpm@linux-foundation.org>
     [not found]       ` <474420EE.4060603@cosmosbay.com>
     [not found]         ` <20071126201717.450e44eb.akpm@linux-foundation.org>
2007-11-27  7:09           ` [PATCH] get rid of NR_OPEN and introduce a sysctl_nr_open Eric Dumazet
2007-11-27  7:25             ` Valdis.Kletnieks
2007-11-27  7:58               ` Eric Dumazet [this message]
2007-11-28  7:52             ` [PATCH, v2] " Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=474BCE0E.4090900@cosmosbay.com \
    --to=dada1@cosmosbay.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox