RE: Kernel profile
Ray Van Tassle-CRV004 (Ray_Van_Tassle-CRV004@email.mot.com)
Tue, 30 Jul 1996 12:29:46 -0500
>
> ________________________________________________________
> To: Van Tassle-CRV004 Ray
> Cc: linux-kernel@vger.rutgers.edu@INTERNET; Mark.Hemment@Uniplex.Co.
UK@INTERNET
> From: Mark.Hemment@Uniplex.Co.UK@INTERNET on Tue, Jul 30, 1996 12:18 PM
> 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?
> 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.
>
> Is this using a sledge hammer to crack a nut?
Maybe, but if you have a LOT of nuts to crack, a sledgehammer might
be better than a nutcracker!
Actually, you don't need two lists. The idle process ("scavenger") could
walk the list and move empty ones to the front.
As I said earlier---you'd need to model (or capture) access patterns.
There's the danger of spending a dollar in order to save a dime.
-30- Ray
> markhe