Messages in this thread | | | Date | Sun, 10 Dec 2000 21:30:14 +0000 (GMT) | From | Tigran Aivazian <> | Subject | Re: [PATCH] NR_RESERVED_FILES broken in 2.4 too |
| |
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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |