On Wed, Jun 25, 2014 at 8:25 AM, Artem Bityutskiy <dedekind1@xxxxxxxxx> 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. Why /proc? Because this is where the current drop_caches mechanism is located. If it should go somewhere else, please do suggest so. The string is a path, i.e., can be either a file or a directory. In case of a directory, we recursively drop all its contents. 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. -- 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
