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: Fri, 27 Jun 2014 10:58:25 +0200 Message-ID: <53AD3231.4060909@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> <53AC0DB4.7070701@itwm.fraunhofer.de> <20140627025501.GY9508@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: =?UTF-8?B?THVrw6HFoSBDemVybmVy?= , Artem Bityutskiy , Thomas Knauth , David Rientjes , Maksym Planeta , Alexander Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Dave Chinner Return-path: In-Reply-To: <20140627025501.GY9508@dastard> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On 06/27/2014 04:55 AM, Dave Chinner wrote: > On Thu, Jun 26, 2014 at 02:10:28PM +0200, Bernd Schubert wrote: >> 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 bench= mark >>>>>>> at a filesystem mount point and unmounting the filesystem in be= tween >>>>>>> benchmark runs. There is no ned to adding kernel functionality = for >>>>>>> somethign that can be so easily acheived by other means, especi= ally >>>>>>> in benchmark environments where *everything* is tightly control= led. >>>>>> >>>>>> If I was a benchmark writer, I would not be willing running it a= s root >>>>>> to be able to mount/unmount, I would not be willing to require t= he >>>>>> customer creating special dedicated partitions for the benchmark= , >>>>>> because this is too user-unfriendly. Or do I make incorrect assu= mptions? >>>>> >>>>> 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 cache= s for >>>> a file. They need a method which guarantees that the caches are dr= opped. >>>> They do not need an advisory method which does not give any guaran= tees. >> >> I'm not sure if a benchmark really needs that so much that >> FADV_DONTNEED isn't sufficient. >> Personally I would also like to know if FADV_DONTNEED succeeded. >> I.e. 'ql-fstest' is to check if the written pattern went to the >> block device and currently it does not know if data really had been >> dropped from the page cache. As it reads files several times this is >> not critical, but only would be a nice to have - nothing worth to >> add a new syscall. > > ql-test is not a benchmark, it's a data integrity test. The re-read > verification problem is easily solved by using direct IO to read the > files directly without going through the page cache. Indeed, direct > IO will invalidate cached pages over the range it reads before it > does the read, so the guarantee that you are after - no cached pages > when the read is done - is also fulfilled by the direct IO read... > > I really don't understand why people keep trying to make cached IO > behave like uncached IO when we already have uncached IO > interfaces.... =46irstly, direct IO has an entirely different IO pattern, usually much= =20 simpler than buffered through the page cache. Secondly, going through=20 the page cache ensures that page cache buffering is also tested. I'm not at all opposed to open files randomly with direct IO to also=20 test that path and I'm going to add that soon, but only using direct IO= =20 would limit the use case of ql-fstest. Bernd