Re: [PATCH] sysctl: Add a feature to drop caches selectively

[Artem Bityutskiy]

On Thu, 2014-06-26 at 12:36 +0200, Bernd Schubert wrote:
> On 06/26/2014 08:13 AM, Artem Bityutskiy wrote:
> > On Thu, 2014-06-26 at 11:06 +1000, Dave Chinner wrote:
> >> Your particular use case can be handled by directing your benchmark
> >> at a filesystem mount point and unmounting the filesystem in between
> >> benchmark runs. There is no ned to adding kernel functionality for
> >> somethign that can be so easily acheived by other means, especially
> >> in benchmark environments where *everything* is tightly controlled.
> >
> > If I was a benchmark writer, I would not be willing running it as root
> > to be able to mount/unmount, I would not be willing to require the
> > customer creating special dedicated partitions for the benchmark,
> > because this is too user-unfriendly. Or do I make incorrect assumptions?
> 
> But why a sysctl then? And also don't see a point for that at all, why 
> can't the benchmark use posix_fadvise(POSIX_FADV_DONTNEED)?

The latter question was answered - people want a way to drop caches for
a file. They need a method which guarantees that the caches are dropped.
They do not need an advisory method which does not give any guarantees.

As for the first question - this was what I was also asking too, but
without suggesting alternatives. I challenged the authors with the
following:

1. Why the interface would only allow the super user dropping the
caches? How about allowing the file owner or, generally speaking, the
person who is allowed to modify the file, drop the caches?

I alluded that this may be doable with an fd-based interface.

2. What about symlinks? Can I have a choice whether I drop caches
(struct inode, I suppose) for the symlink itself or for the destination
file? Again, fd-based interface would probably naturally allow for this.

3. What about leaving some room for future extensions? E.g., someone may
want to drop only part of a file in the future, who knows. Can we invent
an interface which would allow to be extended in the future, without
breaking older software?

My intention was to encourage the submitter to take some time and come
back with deeper analysis.

And finally, and most importantly, Dave stated that any per-file cache
dropping interface is unlikely going to be accepted at all, because
there is mount/unmount.

So far this is the mane concern the submitter should address.

But I just answered that what Dave suggested is probably not the nicest
way to do this from the user-space perspective, because it requires
superuser privileges, and probably a separate "benchmark-only"
partition.

So if the authors want to sell this new interface (in whatever form) to
the kernel community, they should start with providing a solid use-case,
with some more details, explore alternatives and show how the
alternatives do not work for them.

-- 
Best Regards,
Artem Bityutskiy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/