linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
	linux-xfs@vger.kernel.org, hch@infradead.org
Subject: Re: [PATCH 1/2] xfs: force writes to delalloc regions to unwritten
Date: Wed, 20 May 2020 11:03:54 +1000	[thread overview]
Message-ID: <20200520010354.GR2040@dread.disaster.area> (raw)
In-Reply-To: <20200514174448.GE50849@bfoster>

On Thu, May 14, 2020 at 01:44:48PM -0400, Brian Foster wrote:
> On Thu, May 14, 2020 at 09:33:17AM -0700, Darrick J. Wong wrote:
> ISTM that the right thing to do here is merge this patch, finally fix
> the last known stale data exposure vector, and then perhaps step back
> and think about how we might improve performance of unwritten extents
> (or whatever alternate scheme to avoid stale data exposure we might
> think up) regardless of allocation policy or write path. That might even
> make a decent side topic associated with the SSD allocation policy topic
> proposal Dave recently posted.
> 
> It looks like Christoph already reviewed the patch. I'm not sure if his
> opinion changed it all after the subsequent discussion, but otherwise
> that just leaves Dave's objection. Dave, any thoughts on this given the
> test results and broader context? What do you think about getting this
> patch merged and revisiting the whole unwritten extent thing
> independently?

I guess when we look at this in the broader context of "buffered IO
already sucks real bad for high performance IO" then a few percent
here or there doesn't really matter.

Note, however, that the difference between dio+aio and buffered
writes has nothing to do with unwritten extents - what you are
seeing is the cost of the CPU copying the data into the page cache
in the user process context vs just submitting IO. Essentially, IO
submission time is way higher for buffered IO because of the data
copy, hence a CPU can do less of them per second. IOWs, unwritten
extents are not significant compared to the overhead the page cache
adds to the IO path....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  parent reply	other threads:[~2020-05-20  1:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16  6:15 [PATCH 0/2] xfs: fix stale disk exposure after crash Darrick J. Wong
2020-01-16  6:15 ` [PATCH 1/2] xfs: force writes to delalloc regions to unwritten Darrick J. Wong
2020-01-16 16:47   ` Christoph Hellwig
2020-01-16 23:16     ` Darrick J. Wong
2020-01-19 20:49   ` Dave Chinner
2020-02-03 20:14     ` Darrick J. Wong
2020-05-07 10:32       ` Brian Foster
2020-05-14 16:33         ` Darrick J. Wong
2020-05-14 17:44           ` Brian Foster
2020-05-17  7:48             ` Christoph Hellwig
2020-05-19  0:40               ` Darrick J. Wong
2020-05-20  1:03             ` Dave Chinner [this message]
2020-01-16  6:15 ` [PATCH 2/2] xfs: relax unwritten writeback overhead under some circumstances Darrick J. Wong
2020-01-16 16:49   ` Christoph Hellwig
2020-01-16 23:15     ` Darrick J. Wong
2020-01-16 16:49 ` [PATCH 0/2] xfs: fix stale disk exposure after crash Christoph Hellwig
2020-01-16 23:00   ` Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200520010354.GR2040@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=bfoster@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=hch@infradead.org \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).