From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernd Schubert Subject: Re: [PATCH] sysctl: Add a feature to drop caches selectively Date: Thu, 26 Jun 2014 14:10:28 +0200 Message-ID: <53AC0DB4.7070701@itwm.fraunhofer.de> References: <1403626213-7691-1-git-send-email-mcsim.planeta@gmail.com> <1403677528.7903.103.camel@sauron.fi.intel.com> <20140626010606.GT4453@dastard> <1403763199.20275.39.camel@sauron.fi.intel.com> <53ABF7C4.1000906@itwm.fraunhofer.de> <1403782263.20275.59.camel@sauron.fi.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Dave Chinner , Thomas Knauth , David Rientjes , Maksym Planeta , Alexander Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: =?UTF-8?B?THVrw6HFoSBDemVybmVy?= , Artem Bityutskiy Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On 06/26/2014 01:57 PM, Luk=C3=A1=C5=A1 Czerner wrote: > On Thu, 26 Jun 2014, Artem Bityutskiy wrote: >> 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 benchma= rk >>>>> at a filesystem mount point and unmounting the filesystem in betw= een >>>>> benchmark runs. There is no ned to adding kernel functionality fo= r >>>>> somethign that can be so easily acheived by other means, especial= ly >>>>> in benchmark environments where *everything* is tightly controlle= d. >>>> >>>> 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 assump= tions? >>> >>> 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 drop= ped. >> They do not need an advisory method which does not give any guarante= es. I'm not sure if a benchmark really needs that so much that FADV_DONTNEE= D=20 isn't sufficient. Personally I would also like to know if FADV_DONTNEED succeeded. I.e.=20 'ql-fstest' is to check if the written pattern went to the block device= =20 and currently it does not know if data really had been dropped from the= =20 page cache. As it reads files several times this is not critical, but=20 only would be a nice to have - nothing worth to add a new syscall. Cheers, Bernd