Messages in this thread |  | | From | Mark.Hemment@uniplex ... | Date | Tue, 30 Jul 96 18:11:18 +0100 | Subject | Re: RE: Kernel profile |
| |
Ray wrote: > Michael wrote: >> Any ideas for dramatic speed improvements? :) > How about if an unused member (when f_count dropped to zero) got > placed at the front of the list? > As it is, the "found" one is moved to the end of the list, so wouldn't > the empty ones tend to bubble up? (I don't know the access pattern, > so I'm just guessing.)
I think that was the original intention, but the release function was never written (to much overhead in a function call?). If the list maintained a partial ordering (the reverse order of that mentioned above), then the number of iternations - where the active file structures are examined - could be reduced (as in tty_io.c - simply break out of the loop when the first inactive structure is found).
Time to dream of an ideal (over kill) solution?
How about _two_ free lists for 'file' structures, and one active list. This would require a function call to free a structure (rather than the current 'f_count--'). One free-list contains structures that are inactive, and have had their members zeroed. The second contains structures that are inactive, but not zeroed. get_empty_filp() examines the 'zeroed' free-list first, if none available from there then it tries the 'non-zeroed' list (and zeros the structure). Before returning the structure, it is linked onto the active list.
The 'idle' process could zero the structures, and move them from the non-zeroed list to the zeroed one.
Clearly, this would be fast in allocating a structure, and reduce the number if iterations where the active file structures are searched.
OK, there's overhead in calling the release function (which is very simple - the structures are already doubly-linked - and could be inlined).
Is this using a sledge hammer to crack a nut?
markhe
|  |