From: Jens Axboe <axboe@kernel.dk>
To: John Stoffel <john@quad.stoffel.home>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, hannes@cmpxchg.org, clm@fb.com, jack@suse.cz
Subject: Re: [PATCH 0/6] More graceful flusher thread memory reclaim wakeup
Date: Wed, 20 Sep 2017 13:32:25 -0600 [thread overview]
Message-ID: <8a91a54e-e224-ad79-faac-3f8fe654246a@kernel.dk> (raw)
In-Reply-To: <20170920192909.GA27517@quad.stoffel.home>
On 09/20/2017 01:29 PM, John Stoffel wrote:
> On Tue, Sep 19, 2017 at 01:53:01PM -0600, Jens Axboe wrote:
>> We've had some issues with writeback in presence of memory reclaim
>> at Facebook, and this patch set attempts to fix it up. The real
>> functional change is the last patch in the series, the first 5 are
>> prep and cleanup patches.
>>
>> The basic idea is that we have callers that call
>> wakeup_flusher_threads() with nr_pages == 0. This means 'writeback
>> everything'. For memory reclaim situations, we can end up queuing
>> a TON of these kinds of writeback units. This can cause softlockups
>> and further memory issues, since we allocate huge amounts of
>> struct wb_writeback_work to handle this writeback. Handle this
>> situation more gracefully.
>
> This looks nice, but do you have any numbers to show how this improves
> things? I read the patches, but I'm not strong enough to comment on
> them at all. But I am interested in how this improves writeback under
> pressure, if at all.
Writeback should be about the same, it's mostly about preventing
softlockups and excessive memory usage, under conditions where we are
actively trying to reclaim/clean memory. It was bad enough to cause
softlockups for writeback work processing, while the pending writeback
work units grew to insane lengths.
--
Jens Axboe
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe@kernel.dk>
To: John Stoffel <john@quad.stoffel.home>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, hannes@cmpxchg.org, clm@fb.com, jack@suse.cz
Subject: Re: [PATCH 0/6] More graceful flusher thread memory reclaim wakeup
Date: Wed, 20 Sep 2017 13:32:25 -0600 [thread overview]
Message-ID: <8a91a54e-e224-ad79-faac-3f8fe654246a@kernel.dk> (raw)
In-Reply-To: <20170920192909.GA27517@quad.stoffel.home>
On 09/20/2017 01:29 PM, John Stoffel wrote:
> On Tue, Sep 19, 2017 at 01:53:01PM -0600, Jens Axboe wrote:
>> We've had some issues with writeback in presence of memory reclaim
>> at Facebook, and this patch set attempts to fix it up. The real
>> functional change is the last patch in the series, the first 5 are
>> prep and cleanup patches.
>>
>> The basic idea is that we have callers that call
>> wakeup_flusher_threads() with nr_pages == 0. This means 'writeback
>> everything'. For memory reclaim situations, we can end up queuing
>> a TON of these kinds of writeback units. This can cause softlockups
>> and further memory issues, since we allocate huge amounts of
>> struct wb_writeback_work to handle this writeback. Handle this
>> situation more gracefully.
>
> This looks nice, but do you have any numbers to show how this improves
> things? I read the patches, but I'm not strong enough to comment on
> them at all. But I am interested in how this improves writeback under
> pressure, if at all.
Writeback should be about the same, it's mostly about preventing
softlockups and excessive memory usage, under conditions where we are
actively trying to reclaim/clean memory. It was bad enough to cause
softlockups for writeback work processing, while the pending writeback
work units grew to insane lengths.
--
Jens Axboe
next prev parent reply other threads:[~2017-09-20 19:32 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-19 19:53 [PATCH 0/6] More graceful flusher thread memory reclaim wakeup Jens Axboe
2017-09-19 19:53 ` Jens Axboe
2017-09-19 19:53 ` [PATCH 1/6] buffer: cleanup free_more_memory() flusher wakeup Jens Axboe
2017-09-19 19:53 ` Jens Axboe
2017-09-19 20:05 ` Johannes Weiner
2017-09-19 20:05 ` Johannes Weiner
2017-09-20 14:17 ` Jan Kara
2017-09-20 14:17 ` Jan Kara
2017-09-20 15:18 ` Jens Axboe
2017-09-20 15:18 ` Jens Axboe
2017-09-19 19:53 ` [PATCH 2/6] fs-writeback: provide a wakeup_flusher_threads_bdi() Jens Axboe
2017-09-19 19:53 ` Jens Axboe
2017-09-19 20:05 ` Johannes Weiner
2017-09-19 20:05 ` Johannes Weiner
2017-09-20 14:19 ` Jan Kara
2017-09-20 14:19 ` Jan Kara
2017-09-19 19:53 ` [PATCH 3/6] page-writeback: pass in '0' for nr_pages writeback in laptop mode Jens Axboe
2017-09-19 19:53 ` Jens Axboe
2017-09-19 20:06 ` Johannes Weiner
2017-09-19 20:06 ` Johannes Weiner
2017-09-20 14:35 ` Jan Kara
2017-09-20 14:35 ` Jan Kara
2017-09-20 15:19 ` Jens Axboe
2017-09-20 15:19 ` Jens Axboe
2017-09-19 19:53 ` [PATCH 4/6] fs-writeback: make wb_start_writeback() static Jens Axboe
2017-09-19 19:53 ` Jens Axboe
2017-09-19 20:07 ` Johannes Weiner
2017-09-19 20:07 ` Johannes Weiner
2017-09-20 14:35 ` Jan Kara
2017-09-20 14:35 ` Jan Kara
2017-09-19 19:53 ` [PATCH 5/6] fs-writeback: move nr_pages == 0 logic to one location Jens Axboe
2017-09-19 19:53 ` Jens Axboe
2017-09-19 20:07 ` Johannes Weiner
2017-09-19 20:07 ` Johannes Weiner
2017-09-20 14:41 ` Jan Kara
2017-09-20 14:41 ` Jan Kara
2017-09-20 15:05 ` Jens Axboe
2017-09-20 15:05 ` Jens Axboe
2017-09-20 15:36 ` Jan Kara
2017-09-20 15:36 ` Jan Kara
2017-09-20 15:40 ` Jens Axboe
2017-09-20 15:40 ` Jens Axboe
2017-09-19 19:53 ` [PATCH 6/6] fs-writeback: only allow one inflight and pending !nr_pages flush Jens Axboe
2017-09-19 19:53 ` Jens Axboe
2017-09-19 20:18 ` Johannes Weiner
2017-09-19 20:18 ` Johannes Weiner
2017-09-19 20:39 ` Jens Axboe
2017-09-19 20:39 ` Jens Axboe
2017-09-20 1:57 ` Jens Axboe
2017-09-20 1:57 ` Jens Axboe
2017-09-20 3:10 ` Amir Goldstein
2017-09-20 3:10 ` Amir Goldstein
2017-09-20 4:13 ` Jens Axboe
2017-09-20 4:13 ` Jens Axboe
2017-09-20 6:05 ` Amir Goldstein
2017-09-20 6:05 ` Amir Goldstein
2017-09-20 12:35 ` Jens Axboe
2017-09-20 12:35 ` Jens Axboe
2017-09-20 14:43 ` Jan Kara
2017-09-20 14:43 ` Jan Kara
2017-09-20 19:29 ` [PATCH 0/6] More graceful flusher thread memory reclaim wakeup John Stoffel
2017-09-20 19:29 ` John Stoffel
2017-09-20 19:32 ` Jens Axboe [this message]
2017-09-20 19:32 ` Jens Axboe
2017-09-20 23:11 ` Johannes Weiner
2017-09-20 23:11 ` Johannes Weiner
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=8a91a54e-e224-ad79-faac-3f8fe654246a@kernel.dk \
--to=axboe@kernel.dk \
--cc=clm@fb.com \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=john@quad.stoffel.home \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.