From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751825AbdITTjQ (ORCPT ); Wed, 20 Sep 2017 15:39:16 -0400 Received: from mail.stoffel.org ([104.236.43.127]:58707 "EHLO mail.stoffel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751450AbdITTjL (ORCPT ); Wed, 20 Sep 2017 15:39:11 -0400 X-Greylist: delayed 600 seconds by postgrey-1.27 at vger.kernel.org; Wed, 20 Sep 2017 15:39:10 EDT Date: Wed, 20 Sep 2017 15:29:09 -0400 From: John Stoffel To: Jens Axboe 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 Message-ID: <20170920192909.GA27517@quad.stoffel.home> References: <1505850787-18311-1-git-send-email-axboe@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1505850787-18311-1-git-send-email-axboe@kernel.dk> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. John From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 20 Sep 2017 15:29:09 -0400 From: John Stoffel To: Jens Axboe 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 Message-ID: <20170920192909.GA27517@quad.stoffel.home> References: <1505850787-18311-1-git-send-email-axboe@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1505850787-18311-1-git-send-email-axboe@kernel.dk> Sender: owner-linux-mm@kvack.org List-ID: 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. John -- 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: email@kvack.org