linux-kernel - Re: [PATCH v12 00/20] DAX: Page cache bypass for filesystems on memory storage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20150106004714.6d63023c.akpm@linux-foundation.org>
Date:	Tue, 6 Jan 2015 00:47:14 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Matthew Wilcox <willy@...ux.intel.com>,
	Matthew Wilcox <matthew.r.wilcox@...el.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, Linus Torvalds <torvalds@...ux-foundation.org>,
	Milosz Tanski <milosz@...in.com>
Subject: Re: [PATCH v12 00/20] DAX: Page cache bypass for filesystems on
 memory storage

On Mon, 5 Jan 2015 10:41:43 -0800 Christoph Hellwig <hch@...radead.org> wrote:

> On Wed, Dec 10, 2014 at 09:12:11AM -0500, Matthew Wilcox wrote:
> > On Wed, Dec 10, 2014 at 06:03:47AM -0800, Christoph Hellwig wrote:
> > > What is the status of this patch set?
> > 
> > I have no outstanding bug reports against it.  Linus told me that he
> > wants to see it come through Andrew's tree.  I have an email two weeks
> > ago from Andrew saying that it's on his list.  I would love to see it
> > merged since it's almost a year old at this point.
> 
> And since then another month and aother merge window has passed.  Is
> there any way to speed up merging big patch sets like this one?

I took a look at dax last time and found it to be unreviewable due to
lack of design description, objectives and code comments.  Hopefully
that's been addressed - I should get back to it fairly soon as I chew
through merge window and holiday backlog.

> Another one is non-blocking read one that has real life use on one
> of the biggest server side webapp frameworks but doesn't seem to make
> progress, which is a bit frustrating.

I took a look at pread2() as well and I have two main issues:

- The patchset includes a pwrite2() syscall which has nothing to do
  with nonblocking reads and which was poorly described and had little
  justification for inclusion.

- We've talked for years about implementing this via fincore+pread
  and at least two fincore implementations are floating about.  Now
  along comes pread2() which does it all in one hit.

  Which approach is best?  I expect fincore+pread is simpler, more
  flexible and more maintainable.  But pread2() will have lower CPU
  consumption and lower average-case latency.

  But how *much* better is pread2()?  I expect the difference will be
  minor because these operations are associated with a great big
  cache-stomping memcpy.  If the pread2() advantage is "insignificant
  for real world workloads" then perhaps it isn't the best way to go.

  I just don't know, and diligence requires that we answer the
  question.  But all I've seen in response to these questions is
  handwaving.  It would be a shame to make a mistake because nobody
  found the time to perform the investigation.

Also, integration of pread2() into xfstests is (or was) happening and
the results of that aren't yet known.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/