On Wed, Jun 25, 2014 at 10:25:05AM +0200, Thomas Knauth wrote: > On Wed, Jun 25, 2014 at 8:25 AM, Artem Bityutskiy <dedeki...@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.
We're not likely to ever extend the drop_caches functionality. This is brought up semi-regularly by people that have some slightly narrower use-case for dropping caches. 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. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
