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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
