I tried to add some entries to cache_sizes and cache_sizes_names but i got a
kernel panic upon boot.
So i probably missed something. But, it might actually be better to find a
better solution to this. I got the impression that the kernel folks don't
want the memory size that kmalloc can allocate to be much more than 128k
because they are conserned about memory fragmentation.
I'm not at all into kernel hacking so i might be wrong about some things
here. But one suggestion seems to be to use vmalloc instead of kmalloc since
vmalloc donesn't have the same size limitation that kmalloc has (128k). The
difference is that vmalloc allocates virtual continous memory insted of
Would that be a problem for imon? I guess it's a bit slower...
I'll give it a try but as i said, i'm not very good at this, so if anyone
else is interested please try it yourself :)
Right now we seem to have a limitation in the number of inodes that imon can
You should be able to calculate on it if you know how much memory each inode
entry takes up in the hash table. (i don't).
I can see a very good use for imon/fam to monitor a filesystem that's being
replicated to multiple slaves (webservers) in realtime. This limit is very
much in the way for such applications though.
> -----Ursprungligt meddelande-----
> Fran: Rusty Ballinger [mailto:rusty@xxxxxxxxxxxxxxxxxx]
> Skickat: den 27 februari 2001 09:59
> Till: johan@xxxxxxxx
> Kopia: fam@xxxxxxxxxxx
> Amne: Re: [fam] Max number of inodes?
> > Is there a limit in the number of inodes that imon can monitor?
> > I guess it depends on system resources, is there a way to
> calculate on it?
> > The reason i wonder is that i'm having trouble when i try to monitor a
> > directory that's using 42776 inodes.
> Hmmm, that is interesting. (Presumably it fails the same way when you
> monitor 2 directories, each with 42776/2 inodes? Wait... don't bother to
> check that.)
> > What happens is this (after a while, i'm having a perl script adding
> > directories to FAM):
> > My perl script stops
> > In the console i get many of theese:
> > Kmalloc: Size (196608) Too large!
> > (I have lots of free memory)
> Hmm, it looks like 131072 is the most you can get from one call
> to kmalloc.
> The two places imon allocates memory is when it creates the event queue
> (which it does once, but the size is configurable), and when it grows the
> hash table of monitored dev/inode pairs (which it does whenever the table
> fills up).
> One thing you might try, which might work around the problem easily: in
> mm/slab.c, look for that 131072, and try adding some larger entries to
> cache_sizes and cache_sizes_name. (I have no idea what that might break,
> whether those sizes are arbitrary, etc. If it does make your machine
> burst into flames or summon Satan, at least try to videotape it!) If that
> works, the problem will still be there; it's just that hopefully the limit
> will be higher than the amount of memory it takes to hash the number of
> inodes you're monitoring.
> If that doesn't work (and there's not some
> which can give you as much memory as you ask for), I don't know
> what to try
> other than to fix imon to handle its hash table being split into non-
> contiguous blocks of memory, or to use trees, etc.
Source code, list archive, and docs: http://oss.sgi.com/projects/fam/
To unsubscribe: echo unsubscribe fam | mail majordomo@xxxxxxxxxxx