[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] Correct usage of posix_fadvise in SD?


On Monday 29 September 2008 17:01:16 Brice Figureau wrote:
> On Mon, 2008-09-29 at 10:12 -0400, Josh Fisher wrote:
> > Brice Figureau wrote:
> > > Hi,
> > >
> > > I was looking to the 2.4.2 SD spooling code lately (this was part of
> > > understanding why despooling performances were not that good on my
> > > hardware), when I noticed the following usage of posix_fadvise while
> > > sequentially reading the spool file (despool_data):
> > >
> > > #if defined(HAVE_POSIX_FADVISE) && defined(POSIX_FADV_WILLNEED)
> > >    posix_fadvise(rdcr->spool_fd, 0, 0, POSIX_FADV_WILLNEED);
> > > #endif
> > >
> > > I don't understand why we're telling the kernel to page cache the spool
> > > file we're reading since we won't reuse those data.
> > > Moreover, there is no "DONTNEED" call after despool_data to let the
> > > kernel know it can trash what we read.
> >
> > It allows a non-blocking asynchronous read ahead of the spool file while
> > the SD is working on the previous buffer.
>
> OK, understood, but shouldn't we tell the kernel which part of the file
> we're currently reading (at least giving the current offset) ?
>
> > > I thought that something along the line of this in despool_data:
> > > #if defined(HAVE_POSIX_FADVISE) && defined(POSIX_FADV_SEQUENTIAL)
> > >    posix_fadvise(rdcr->spool_fd, 0, 0, POSIX_FADV_SEQUENTIAL);
> > > #endif
> > > #if defined(HAVE_POSIX_FADVISE) && defined(POSIX_FADV_NOREUSE)
> > >    posix_fadvise(rdcr->spool_fd, 0, 0, POSIX_FADV_NOREUSE);
> > > #endif
> >
> > The POSIX_FADV_SEQUENTIAL doubles the size of the readahead window. I
> > don't know if that is good or bad. I suspect it depends on the hardware,
> > amount of RAM, etc.
>
> I'll bench this later.
>
> > The POSIX_FADV_NOREUSE is definitely not helpful.
> >
> >  From the posix_fadvise() man page:
> >     In  kernels before 2.6.18, POSIX_FADV_NOREUSE had the same semantics
> > as POSIX_FADV_WILLNEED.
> >     This was probably a  bug;  since  kernel  2.6.18, this flag is a
> > no-op.
>
> It seems I have outdated manpages :-(
> I'm now looking to a newer version which have the above snippets.
> So NOREUSE is of no use :-)
>
> > > And a few POSIX_FADV_DONTNEED after each block read with the correct
> > > offset and length to tell the pagecache we don't need this part
> > > anymore.
> > >
> > > Does it make sense?
> > > Or did I miss something?
> >
> > I agree that the POSIX_FADV_DONTNEED could be useful when reading the
> > spool file. The kernel probably will see the spool file pages as being
> > more recently used. So when cache space is needed, it could cause the
> > kernel to free useful pages just to keep the spool file pages. It has no
> > way to know they will never be used again. The use of
> > POSIX_FADV_DONTNEED could help keep the cache more efficiently used.
>
> Yes, that was what I was thinking. I think it is frequent to have a
> spool size way larger than the available physical memory. Since the SD
> won't reuse the read content, there is no need for the kernel to keep
> this unusefull data in the page cache.
> I'll try to bench (speed and pagecache use) this later this week (If I
> can setup a blackhole sd), and I'll keep the list posted with the
> results.

I'll be *very* interested to see your results.  I don't doubt that we can 
tweak the code and improve it, but tests would really help.

If you want to eliminate the write, just comment out the  
write_block_to_device(dcr) after the posix_fadvise(), but only do so in a 
real test situation since it will likely leave you with a broken volume.

Regards,

Kern

PS: Josh, thanks for providing a nice explanation :-)

>
> Thanks for the explanations,



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-devel mailing list
Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/bacula-devel


This mailing list archive is a service of Copilot Consulting.