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


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