[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1889689.0axyUkdxkf@wuerfel>
Date: Wed, 02 Mar 2016 10:15:02 +0100
From: Arnd Bergmann <arnd@...db.de>
To: "Darrick J. Wong" <darrick.wong@...cle.com>
Cc: axboe@...nel.dk, hch@...radead.org, akpm@...ux-foundation.org,
torvalds@...ux-foundation.org, martin.petersen@...cle.com,
linux-api@...r.kernel.org, linux-kernel@...r.kernel.org,
shane.seymour@....com, bfields@...ldses.org,
linux-fsdevel@...r.kernel.org, jlayton@...chiereds.net
Subject: Re: [PATCH v5.1 0/2] create BLKZEROOUT ioctl that invalidates page cache
On Tuesday 01 March 2016 20:09:32 Darrick J. Wong wrote:
> This is (yet another) repost of the patch series that fixes the
> existing BLKZEROOUT ioctl to invalidate the page cache if the zeroing
> command to the underlying device succeeds. This patch is against
> 4.5-rc6 and hasn't changed much in months.
>
> The new BLKZEROOUT ioctl has the same semantics as the old one, but it
> invalidates the page cache to prevent surprising results, just like
> how dio writes invalidate page cache.
>
> I've incorporated all the feedback I've received into these patches,
> but haven't heard yea or nay or anything at all from the maintainer.
> Will someone please pick this up for 4.6?
>
> Comments and questions are, as always, welcome.
I'm missing the background on this, just saw the patch fly by,
so sorry if this has been asked before:
Why do you want to invalidate the cache? Is this to save RAM
or is something else going to write here and you have to invalidate
it for correctness?
If you just want to save RAM, would it be possible to instead
point the page cache to the empty zero page to speed up subsequent
reads? Maybe that just causes more complexity than it helps.
Arnd
Powered by blists - more mailing lists