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:
pgp4GqQtb1mli.pgp
Description: PGP signature
- Follow-Ups:
- Re: [PATCH] get rid of NR_OPEN and introduce a sysctl_nr_open
- From: Eric Dumazet <[email protected]>
- Re: [PATCH] get rid of NR_OPEN and introduce a sysctl_nr_open
- References:
- [PATCH] get rid of NR_OPEN and introduce a sysctl_nr_open
- From: Eric Dumazet <[email protected]>
- [PATCH] get rid of NR_OPEN and introduce a sysctl_nr_open
- Prev by Date: Re: 2.6.24-rc3-mm1 - brick my Dell Latitude D820
- Next by Date: Re: Booting latest linux kernel(2.6.20) on MPC8548ECDS
- Previous by thread: [PATCH] get rid of NR_OPEN and introduce a sysctl_nr_open
- Next by thread: Re: [PATCH] get rid of NR_OPEN and introduce a sysctl_nr_open
- Index(es):
 |