On Thu, 26 Jun 2014, Artem Bityutskiy wrote: > Date: Thu, 26 Jun 2014 14:31:03 +0300 > From: Artem Bityutskiy <dedekind1@xxxxxxxxx> > To: Bernd Schubert <bernd.schubert@xxxxxxxxxxxxxxxxxx> > Cc: Dave Chinner <david@xxxxxxxxxxxxx>, Thomas Knauth <thomas.knauth@xxxxxx>, > David Rientjes <rientjes@xxxxxxxxxx>, > Maksym Planeta <mcsim.planeta@xxxxxxxxx>, > Alexander Viro <viro@xxxxxxxxxxxxxxxxxx>, linux-fsdevel@xxxxxxxxxxxxxxx, > linux-kernel@xxxxxxxxxxxxxxx > Subject: Re: [PATCH] sysctl: Add a feature to drop caches selectively > > 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. I think that Dave is right in that if it's just for a "benchmarking" purposes, then there is no need for a new special interface for dropping caches. There is mount/umount and drop_caches which should be more than enough for any benchmark. And while it's true that you'd likely need superuser privileges for mount/umount, the same is true about drop_caches, isn't it ? > > 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. Yes please, let's see some solid use-case for this. -Lukas -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
