linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Wayne Davison <wayned@samba.org>
To: Ben Gamari <bgamari.foss@gmail.com>
Cc: linux-kernel@vger.kernel.org, rsync@lists.samba.org, linux-mm@kvack.org
Subject: Re: fadvise DONTNEED implementation (or lack thereof)
Date: Sat, 6 Nov 2010 09:23:49 -0700	[thread overview]
Message-ID: <AANLkTi=mprHyKd=bvr=n9UaN_KVjd3acir1pigayqHKT@mail.gmail.com> (raw)
In-Reply-To: <87lj597hp9.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]

On Wed, Nov 3, 2010 at 10:58 PM, Ben Gamari <bgamari.foss@gmail.com> wrote:

> It looks like a few folks have discussed addressing the issue in the past,
> but nothing has happened as of 2.6.36.


Yeah, the linux code for this has long been buggy and near useless.  What is
really needed is a way for some file access to be marked as generating
low-priority cache data into the filesystem cache.  Such a flag should only
apply to newly cached data, so that copying a file that was cached by some
other program would not lower its cache priority (nor kick it out of the
cache).  If some other process comes along and reads from the low-priority
cache with a normal-priority read, it should get upgraded to normal
priority.  Something like that seems pretty simple and useful.

As for rsync, all current implementations of cache dropping are way too
klugey to go into rsync.  I'd personally suggest that someone create a
linux-specific pre-load library that overrides read() and write() calls and
use that when running rsync (or whatever else) to implement the extreme
weirdness that is currently needed for cache twiddling.

..wayne..

[-- Attachment #2: Type: text/html, Size: 1434 bytes --]

  reply	other threads:[~2010-11-06 16:23 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-04  5:58 Ben Gamari
2010-11-06 16:23 ` Wayne Davison [this message]
2010-11-09  7:28 ` KOSAKI Motohiro
2010-11-09  8:03   ` KOSAKI Motohiro
2010-11-09 12:54   ` Ben Gamari
2010-11-14  5:09     ` KOSAKI Motohiro
2010-11-14  5:20       ` Ben Gamari
2010-11-14 21:33         ` Brian K. White
2010-11-15  6:07       ` Minchan Kim
2010-11-15  7:09         ` KOSAKI Motohiro
2010-11-15  7:19           ` Minchan Kim
2010-11-15  7:28             ` KOSAKI Motohiro
2010-11-15  7:46               ` Minchan Kim
2010-11-15 12:46               ` Ben Gamari
2010-11-15  8:47         ` Peter Zijlstra
2010-11-15  9:05           ` Minchan Kim
2010-11-15 14:48             ` Rik van Riel
2010-11-17 10:16               ` Minchan Kim
2010-11-17 11:15                 ` Minchan Kim
2010-11-17 16:22                 ` Rik van Riel
2010-11-18  2:47                   ` Minchan Kim
2010-11-18  3:24                     ` Rik van Riel
2010-11-18  3:46                       ` Minchan Kim
2010-11-15  9:10           ` KOSAKI Motohiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='AANLkTi=mprHyKd=bvr=n9UaN_KVjd3acir1pigayqHKT@mail.gmail.com' \
    --to=wayned@samba.org \
    --cc=bgamari.foss@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rsync@lists.samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox