mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Valdis.Kletnieks@vt.edu
To: Eric Dumazet <dada1@cosmosbay.com>
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 02:25:56 -0500	[thread overview]
Message-ID: <4651.1196148356@turing-police.cc.vt.edu> (raw)
In-Reply-To: Your message of "Tue, 27 Nov 2007 08:09:19 +0100." <474BC29F.4060706@cosmosbay.com>

[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]

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.

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?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

  reply	other threads:[~2007-11-27  7:27 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           ` Eric Dumazet
2007-11-27  7:25             ` Valdis.Kletnieks [this message]
2007-11-27  7:58               ` Eric Dumazet
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=4651.1196148356@turing-police.cc.vt.edu \
    --to=valdis.kletnieks@vt.edu \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=dada1@cosmosbay.com \
    --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

all inboxes | Powered by JetHome®