lkml.org 
[lkml]   [1996]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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


\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.020 / U:3.724 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site