[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] Correct usage of posix_fadvise in SD?
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
Thanks for the explanations,
Brice Figureau <brice+bacula@xxxxxxxxxxxxxxxx>
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
Bacula-devel mailing list
This mailing list archive is a service of Copilot Consulting.