>Hello!
>
>> >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.
My point is that the kernel has to run stable even if update is not
running. And even if update is running there's a very large window to
leak inodes anyway.
>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:
Infact. And there's people that tell update to smart-sync only every 50
sec.
>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!
Yes you need to reboot (right now).
>> 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
As expected. With a bit more malicious proggy like the one I developed to
exploit the 2.2.[01] inode leak and eat 128mbyte in 20 sec here,
2.2.2-pre2 leaks easily too with update running. (Linus, the inode-max
limit was 2000).
Thanks for the testing.
Andrea Arcangeli
-
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/