linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Thomas Knauth <thomas.knauth@gmx.de>
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 12:56:24 +0300	[thread overview]
Message-ID: <1403690184.20275.11.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <CABhLV03_PNFiwsvt+yitcsKxz5TeVECCFavdNkbgQ+XzQqASaw@mail.gmail.com>

On Wed, 2014-06-25 at 10:25 +0200, Thomas Knauth wrote:
> 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:

Thanks for the answer, although you forgot to comment on the question
about possibly extending the new interface to work with file ranges in
the future. For example, I have a 2 TiB file, and I am only interested
in dropping caches for the first couple of gigabytes. Would I extend
your interface, or would I come up with another one?

> 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.

Sounds like a reasonable motivation for me.

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

I do not have particular suggestions, just pulling the information about
how much efforts were put into choosing the interface.

> 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.

OK, thanks.

-- 
Best Regards,
Artem Bityutskiy


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

Thread overview: 26+ 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
2014-06-25  9:56       ` Artem Bityutskiy [this message]
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  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: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=1403690184.20275.11.camel@sauron.fi.intel.com \
    --to=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=thomas.knauth@gmx.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).