On Sun, 10 Dec 2000, Tigran Aivazian wrote:
> Ok, let's slowly understand each other. The scenario you suggest is:
>
> a) measure nr_free_files and let root exhaust all freelist entries. Now
> the freelist is empty and nr_free_files = 0.
>
> b) now let the user app allocate (from the slab cache) lots of new file
> structures. He can keep doing so until nr_files hits max_files.
>
> Now what? Now root tries to allocate some and obviously he can't because
> the freelist is empty
.
... and neither can he allocate from the slab cache since nr_files ==
max_files now.
Now, if I understand your proposal correctly -- you would like to redefine
NR_RESERVED_FILES to be _guaranteed_ for root at any time regardless of
the allocation pattern instead of their current definition as guaranteed
number of elements on the _freelist_? Right?
So you would like to deny normal users some requests from the slab cache
if otherwise root's new NR_RESERVED_FILES wouldn't be honoured?
Did I understand your idea correctly? Such policy sounds sensible but is
certainly a redesign of file allocator and should be carefully checked if
it's ok in all cases...
If you agree with the above then we never disagreed to begin with -- I
just insisted (and still insist) that it is the expected behaviour,
perhaps not 100% satisfactory.
Also, I agree with your suggestion to increase NR_RESERVED_FILES -- with
both policies (the current and your new one) the current value of 10 is
way too small.
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
