From: Dave Chinner <david@fromorbit.com>
To: Chris Mason <clm@fb.com>
Cc: "linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH 09/24] xfs: don't allow log IO to be throttled
Date: Sat, 3 Aug 2019 09:28:14 +1000 [thread overview]
Message-ID: <20190802232814.GP7777@dread.disaster.area> (raw)
In-Reply-To: <7093F5C3-53D2-4C49-9C0D-64B20C565D18@fb.com>
On Fri, Aug 02, 2019 at 02:11:53PM +0000, Chris Mason wrote:
> On 1 Aug 2019, at 19:58, Dave Chinner wrote:
> I can't really see bio->b_ioprio working without the rest of the IO
> controller logic creating a sensible system,
That's exactly the problem we need to solve. The current situation
is ... untenable. Regardless of whether the io.latency controller
works well, the fact is that the wbt subsystem is active on -all-
configurations and the way it "prioritises" is completely broken.
> framework to define weights etc. My question is if it's worth trying
> inside of the wbt code, or if we should just let the metadata go
> through.
As I said, that doesn't solve the problem. We /want/ critical
journal IO to have higher priority that background metadata
writeback. Just ignoring REQ_META doesn't help us there - it just
moves the priority inversion to blocking on request queue tags.
> Tejun reminded me that in a lot of ways, swap is user IO and it's
> actually fine to have it prioritized at the same level as user IO. We
I think that's wrong. Swap *in* could have user priority but swap
*out* is global as there is no guarantee that the page being swapped
belongs to the user context that is reclaiming memory.
Lots of other user and kernel reclaim contexts may be waiting on
that swap to complete, so it's important that swap out is not
arbitrarily delayed or susceptible to priority inversions. i.e. swap
out must take priority over swap-in and other user IO because that
IO may require allocation to make progress via swapping to free
"user" file data cached in memory....
> don't want to let a low prio app thrash the drive swapping things in and
> out all the time,
Low priority apps will be throttled on *swap in* IO - i.e. by their
incoming memory demand. High priority apps should be swapping out
low priority app memory if there are shortages - that's what priority
defines....
> other higher priority processes aren't waiting for the memory. This
> depends on the cgroup config, so wrt your current patches it probably
> sounds crazy, but we have a lot of data around this from the fleet.
I'm not using cgroups.
Core infrastructure needs to work without cgroups being configured
to confine everything in userspace to "safe" bounds, and right now
just running things in the root cgroup doesn't appear to work very
well at all.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2019-08-02 23:29 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-01 2:17 [RFC] [PATCH 00/24] mm, xfs: non-blocking inode reclaim Dave Chinner
2019-08-01 2:17 ` [PATCH 01/24] mm: directed shrinker work deferral Dave Chinner
2019-08-02 15:27 ` Brian Foster
2019-08-04 1:49 ` Dave Chinner
2019-08-05 17:42 ` Brian Foster
2019-08-05 23:43 ` Dave Chinner
2019-08-06 12:27 ` Brian Foster
2019-08-06 22:22 ` Dave Chinner
2019-08-07 11:13 ` Brian Foster
2019-08-01 2:17 ` [PATCH 02/24] shrinkers: use will_defer for GFP_NOFS sensitive shrinkers Dave Chinner
2019-08-02 15:27 ` Brian Foster
2019-08-04 1:50 ` Dave Chinner
2019-08-01 2:17 ` [PATCH 03/24] mm: factor shrinker work calculations Dave Chinner
2019-08-02 15:08 ` Nikolay Borisov
2019-08-04 2:05 ` Dave Chinner
2019-08-02 15:31 ` Brian Foster
2019-08-01 2:17 ` [PATCH 04/24] shrinker: defer work only to kswapd Dave Chinner
2019-08-02 15:34 ` Brian Foster
2019-08-04 16:48 ` Nikolay Borisov
2019-08-04 21:37 ` Dave Chinner
2019-08-07 16:12 ` kbuild test robot
2019-08-07 18:00 ` kbuild test robot
2019-08-01 2:17 ` [PATCH 05/24] shrinker: clean up variable types and tracepoints Dave Chinner
2019-08-01 2:17 ` [PATCH 06/24] mm: reclaim_state records pages reclaimed, not slabs Dave Chinner
2019-08-01 2:17 ` [PATCH 07/24] mm: back off direct reclaim on excessive shrinker deferral Dave Chinner
2019-08-01 2:17 ` [PATCH 08/24] mm: kswapd backoff for shrinkers Dave Chinner
2019-08-01 2:17 ` [PATCH 09/24] xfs: don't allow log IO to be throttled Dave Chinner
2019-08-01 13:39 ` Chris Mason
2019-08-01 23:58 ` Dave Chinner
2019-08-02 8:12 ` Christoph Hellwig
2019-08-02 14:11 ` Chris Mason
2019-08-02 18:34 ` Matthew Wilcox
2019-08-02 23:28 ` Dave Chinner [this message]
2019-08-05 18:32 ` Chris Mason
2019-08-05 23:09 ` Dave Chinner
2019-08-01 2:17 ` [PATCH 10/24] xfs: fix missed wakeup on l_flush_wait Dave Chinner
2019-08-01 2:17 ` [PATCH 11/24] xfs:: account for memory freed from metadata buffers Dave Chinner
2019-08-01 8:16 ` Christoph Hellwig
2019-08-01 9:21 ` Dave Chinner
2019-08-06 5:51 ` Christoph Hellwig
2019-08-01 2:17 ` [PATCH 12/24] xfs: correctly acount for reclaimable slabs Dave Chinner
2019-08-06 5:52 ` Christoph Hellwig
2019-08-06 21:05 ` Dave Chinner
2019-08-01 2:17 ` [PATCH 13/24] xfs: synchronous AIL pushing Dave Chinner
2019-08-05 17:51 ` Brian Foster
2019-08-05 23:21 ` Dave Chinner
2019-08-06 12:29 ` Brian Foster
2019-08-01 2:17 ` [PATCH 14/24] xfs: tail updates only need to occur when LSN changes Dave Chinner
2019-08-05 17:53 ` Brian Foster
2019-08-05 23:28 ` Dave Chinner
2019-08-06 5:33 ` Dave Chinner
2019-08-06 12:53 ` Brian Foster
2019-08-06 21:11 ` Dave Chinner
2019-08-01 2:17 ` [PATCH 15/24] xfs: eagerly free shadow buffers to reduce CIL footprint Dave Chinner
2019-08-05 18:03 ` Brian Foster
2019-08-05 23:33 ` Dave Chinner
2019-08-06 12:57 ` Brian Foster
2019-08-06 21:21 ` Dave Chinner
2019-08-01 2:17 ` [PATCH 16/24] xfs: Lower CIL flush limit for large logs Dave Chinner
2019-08-04 17:12 ` Nikolay Borisov
2019-08-01 2:17 ` [PATCH 17/24] xfs: don't block kswapd in inode reclaim Dave Chinner
2019-08-06 18:21 ` Brian Foster
2019-08-06 21:27 ` Dave Chinner
2019-08-07 11:14 ` Brian Foster
2019-08-01 2:17 ` [PATCH 18/24] xfs: reduce kswapd blocking on inode locking Dave Chinner
2019-08-06 18:22 ` Brian Foster
2019-08-06 21:33 ` Dave Chinner
2019-08-07 11:30 ` Brian Foster
2019-08-07 23:16 ` Dave Chinner
2019-08-01 2:17 ` [PATCH 19/24] xfs: kill background reclaim work Dave Chinner
2019-08-01 2:17 ` [PATCH 20/24] xfs: use AIL pushing for inode reclaim IO Dave Chinner
2019-08-07 18:09 ` Brian Foster
2019-08-07 23:10 ` Dave Chinner
2019-08-08 16:20 ` Brian Foster
2019-08-01 2:17 ` [PATCH 21/24] xfs: remove mode from xfs_reclaim_inodes() Dave Chinner
2019-08-01 2:17 ` [PATCH 22/24] xfs: track reclaimable inodes using a LRU list Dave Chinner
2019-08-08 16:36 ` Brian Foster
2019-08-09 0:10 ` Dave Chinner
2019-08-01 2:17 ` [PATCH 23/24] xfs: reclaim inodes from the LRU Dave Chinner
2019-08-08 16:39 ` Brian Foster
2019-08-09 1:20 ` Dave Chinner
2019-08-09 12:36 ` Brian Foster
2019-08-11 2:17 ` Dave Chinner
2019-08-11 12:46 ` Brian Foster
2019-08-01 2:17 ` [PATCH 24/24] xfs: remove unusued old inode reclaim code Dave Chinner
2019-08-06 5:57 ` [RFC] [PATCH 00/24] mm, xfs: non-blocking inode reclaim Christoph Hellwig
2019-08-06 21:37 ` Dave Chinner
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=20190802232814.GP7777@dread.disaster.area \
--to=david@fromorbit.com \
--cc=axboe@kernel.dk \
--cc=clm@fb.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.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).