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 [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
