Messages in this thread |  | | Date | Tue, 30 Jul 1996 12:29:46 -0500 | From | "Ray Van Tassle-CRV004" <> | Subject | RE: 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
|  |