Re: Re: can enbd server run in kernel?

"Also sprach Ming Zhang:"
> > Well, I have introduced map caching and used a look ahead of 1MB, and
> > it helps, but not greatly.  At the sizes of this test, the disk writes
> > are all cached in VMS anyway and measure very fast, as fast as writes to
> > memory. When I pushed mmaps up to 1MB cached, they took about 220us to
> > make, 10-20 times as long as for 4KB maps. 
> > 
> can this look ahead to be larger? like ~100MB?

Not in my tests (localhost, small resource, etc.). ANyway, it would be
silly - the cost of making and revoking the cache looks like it would
be huge, several seconds each time. And the cache would be revoked by
every miss. Better to split the cache into several small parts if one goes
that way. 16 of 1MB each might be reasonable.

But I am just looking for some indication that it'sthe right way to go.

> > With 4KB requests, and 1MB maps cached (and all msyncs failing, but it
> > doesn't matter since there is only one thread), I get:
> > 
> > % time     seconds  usecs/call     calls    errors syscall
> >   0.42    0.108365         223       486           old_mmap
> >   0.36    0.091915         190       485           munmap
> >   0.11    0.029165           6      4927           write
> >   0.11    0.028450           6      4972           read
> >   0.07    0.017984           4      4921      4921 msync
> >   4.20    1.072929         118      9074           send
> >   0.38    0.097121           8     11944           recv
> > 
> > The test prveviously looked like this:
> > 
> > With mmapping on:
> > 
> > % time     seconds  usecs/call     calls    errors syscall
> >   0.18    0.046989          10      4925           old_mmap
> >   0.13    0.035787           7      4925           munmap
> >   0.11    0.030343           6      4931           write
> >   0.10    0.026622           5      4980           read
> >   2.46    0.657184         132      4988           send
> >   0.29    0.078830           8      9910           recv
> > 
> en, i do not realize that this mmap took so many time. so strange. :P i

It looks maybe proportional to the log of the size of the map. 10us for
one page and 220us for 256 pages.

> blindly guess it needs to lock some pages already in system?

I think it has to do some searching.

> if strace can not do this well, i guess we have to use something like
> oprofile or kernprof.

Peter