> 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 kernel-memory-allocation-routine
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.
--Rusty
--
Source code, list archive, and docs: http://oss.sgi.com/projects/fam/
To unsubscribe: echo unsubscribe fam | mail majordomo@xxxxxxxxxxx