[PATCH]: fdalloc optimization

[Divacky Roman]

On Mon, Aug 22, 2005 at 12:13:39PM -0400, Kris Kennaway wrote:
> On Mon, Aug 22, 2005 at 03:55:00PM +0200, Dag-Erling Sm?rgrav wrote:
> > Kris Kennaway <kris at obsecurity.org> writes:
> > > On Sun, Aug 21, 2005 at 10:45:46AM +0200, Divacky Roman wrote:
> > > > I made a patch for fdalloc which could speed it up a bit, its stored under
> > > > kern/85176 or http://hysteria.sk/~neologism/kern_descrip.patch
> > > That's all nice and everything, but *does* it speed it up a bit? :-)
> > 
> > It won't make a measurable difference, but that doesn't mean the patch
> > is wrong.
> 
> Just that it's not an optimization, as it was advertised :) As
> Poul-Henning said, if you can't measure a performance difference
> either way then sell it some other way.


here is my analyze of the problem - if its correct then the patch speeds it up

the code in fact looks:

if (fd == fdp->fd_freefile)
           fdp->fd_freefile = fd_first_free(fdp, fd, fdp->fd_nfiles);
fdp->fd_freefile = fd_first_free(fdp, fd, fdp->fd_nfiles);

fd cannot be lower then fd_freefile (because fd is technically the first
available fd)
if fd > fd_freefile it makes no sense to reset it because we would make a gap
in the bitarray
if fd == fd_freefile we must reset it because the fd is not free anymore

anyway - there is clear duplicity


the fd_freefile hinting idea is quite clear (if fd_freefile is first available
fd it makes sense to start searching from here cause everything before that is
used)


roman