> >This is after running inode hog. Fine to this point. (However in clean
> >2.2.2-pre2 the number is bigger, that's fine too as I have some free memory)
> It's not fine according to me. Could you try to kill your update daemon
> and see how much you can grow such number with many of your hog test?
It is going through the roof and killing my machine with OOM without update,
but I see that Linus' point about update is valid also.
Just to add. If I run my hog in wrong time (e.g. just after update synced disk,
and sleeps for another 5 sec), I have whole 5 sec to grow inodes,
then update wakes up and growing stops:
mordor:~$ cat /proc/sys/fs/inode-state
4844 3 1 0 0 0 0
(limit is still 2048)
It is a pity that I lost 2.5 times more memory that I supposed to and I have
no way to reclaim it back. 4844 inodes is somewhat more than I need at home
and I need to *reboot* to get that memory back!
> The only place I can see that sync inode to disk and so that generate
> freeable inodes is sync_old_buffers() that it's recalled only by the
> update daemon. I don't want a kernel that base it's stability on the
> update userspace daemon.
>
> According to me you should able to leak 2.2.2-pre2 as 2.2.1. You could try
> with a proggy like this (inspired to your original one):
Oops!!! I have update running, but inodes still leaks with this proggy.
mordor:~$ cat /proc/sys/fs/inode-state
33754 7 1 0 0 0 0
mordor:~$ ps ax | grep update
10 ? S 0:01 /sbin/update
mordor:~$ uname -a
Linux mordor 2.2.2 #38 Sat Feb 6 13:28:17 MSK 1999 i586 unknown
This is clean 2.2.2-pre2
Bye,
Oleg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/