Re: PATCH - raise max_anon limit

[Tim Hockin <thockin@sun.com>]

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

On Wed, Feb 11, 2004 at 12:38:11PM -0800, Linus Torvalds wrote:
> > Maybe that is just the simplest answer?  It can be a simple constant that is
> > changeable at compile time, and leave it at that
> > 
> > What's most likely to cause the least argument?
> 
> I'd suggest just raising it to 64k or so, that's likely to be acceptable, 
> and it's a static 8kB array. That's likely not much more than the code 
> needed to worry about dynamic entries, yet I'd assume that changing it 
> from 256 to 64k is going to make most people say "enough".

How's this then?  It doesn't get any simpler..

-- 
Tim Hockin
Sun Microsystems, Linux Software Engineering
thockin@sun.com
All opinions are my own, not Sun's

[-- Attachment #2: max_anon_raise-2.6.2-1.diff --]
[-- Type: text/plain, Size: 504 bytes --]

===== fs/super.c 1.110 vs edited =====
--- 1.110/fs/super.c	Sun Oct  5 01:07:55 2003
+++ edited/fs/super.c	Wed Feb 11 11:56:02 2004
@@ -535,7 +535,8 @@
  * filesystems which don't use real block-devices.  -- jrs
  */
 
-enum {Max_anon = 256};
+/* you can raise this as high as 2^MINORBITS if you REALLY need more */
+enum {Max_anon = 65536};
 static unsigned long unnamed_dev_in_use[Max_anon/(8*sizeof(unsigned long))];
 static spinlock_t unnamed_dev_lock = SPIN_LOCK_UNLOCKED;/* protects the above */