All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Knauth <thomas.knauth@gmx.de>
To: dedekind1@gmail.com
Cc: David Rientjes <rientjes@google.com>,
	Maksym Planeta <mcsim.planeta@gmail.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sysctl: Add a feature to drop caches selectively
Date: Wed, 25 Jun 2014 10:25:05 +0200	[thread overview]
Message-ID: <CABhLV03_PNFiwsvt+yitcsKxz5TeVECCFavdNkbgQ+XzQqASaw@mail.gmail.com> (raw)
In-Reply-To: <1403677528.7903.103.camel@sauron.fi.intel.com>

On Wed, Jun 25, 2014 at 8:25 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> Plus some explanations WRT why proc-based interface and what would be
> the alternatives, what if tomorrow we want to extend the functionality
> and drop caches only for certain file range, is this only for regular
> files or also for directories, why posix_fadvice(DONTNEED) is not
> sufficient.

I suggested the idea originally. Let me address each of your questions in turn:

Why a selective drop? To have a middle ground between echo 2 >
drop_caches and echo 3 > drop_caches. When is this interesting? My
particular use case was benchmarking. I wanted to repeatedly measure
the timing when things were read from disk. Dropping everything from
the cache, also drops useful things, not just the few files your
benchmark intends to measure.

Why /proc? Because this is where the current drop_caches mechanism is
located. If it should go somewhere else, please do suggest so.

The string is a path, i.e., can be either a file or a directory. In
case of a directory, we recursively drop all its contents.

Why not use posix_fadvice()? Because it is exactly this, an advice.
The kernel is free to do whatever, i.e., also ignore the request. We
want a mechanism that reliably drops select content from the cache.

  reply	other threads:[~2014-06-25  8:25 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-24 16:10 [PATCH] sysctl: Add a feature to drop caches selectively Maksym Planeta
2014-06-24 21:59 ` David Rientjes
2014-06-25  6:25   ` Artem Bityutskiy
2014-06-25  8:25     ` Thomas Knauth [this message]
2014-06-25  9:56       ` Artem Bityutskiy
2014-06-25 13:23         ` Thomas Knauth
2014-06-25 13:30           ` Artem Bityutskiy
2014-06-25 13:42           ` Artem Bityutskiy
2014-06-26  9:30             ` Maksym Planeta
2014-06-25 10:03       ` Artem Bityutskiy
2014-06-25 13:19         ` Thomas Knauth
2014-06-25 22:15       ` Pavel Machek
2014-06-26  1:06       ` Dave Chinner
2014-06-26  6:13         ` Artem Bityutskiy
2014-06-26 10:36           ` Bernd Schubert
2014-06-26 11:31             ` Artem Bityutskiy
2014-06-26 11:57               ` Lukáš Czerner
2014-06-26 12:10                 ` Bernd Schubert
2014-06-27  2:55                   ` Dave Chinner
2014-06-27  2:55                     ` Dave Chinner
2014-06-27  8:58                     ` Bernd Schubert
2014-06-27  8:41                 ` Matthias Schniedermeyer
2014-06-27  9:04                   ` Lukáš Czerner
2014-06-27  9:08                   ` Artem Bityutskiy
2014-06-27  9:08                     ` Artem Bityutskiy
2014-06-27  9:09                     ` Bityutskiy, Artem
2014-06-27  9:09                       ` Bityutskiy, Artem
2014-06-27  2:48           ` Dave Chinner
     [not found] <CACVxJT_6sp=KDy=jCNBypYapKv_59W8LxFU4OiJEm6gt_SuZKg@mail.gmail.com>
2014-06-25 11:21 ` Alexey Dobriyan

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=CABhLV03_PNFiwsvt+yitcsKxz5TeVECCFavdNkbgQ+XzQqASaw@mail.gmail.com \
    --to=thomas.knauth@gmx.de \
    --cc=dedekind1@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcsim.planeta@gmail.com \
    --cc=rientjes@google.com \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.