From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757743AbcDABBo (ORCPT ); Thu, 31 Mar 2016 21:01:44 -0400 Received: from ipmail06.adl2.internode.on.net ([150.101.137.129]:21371 "EHLO ipmail06.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750720AbcDABBn (ORCPT ); Thu, 31 Mar 2016 21:01:43 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BeDgBTx/1WPDGaLHldgzOBUIZqoBoBAQEBAQEGjBKFY4QPhgcEAgKBRk0BAQEBAQEHAQEBAUJAhEIBAQQyASMjEAgDGAklDwUlAwcaE4gmw2UBAQgCHhmFPYUOihQFl3KNfo8XXo44hF0oMIhtAQEB Date: Fri, 1 Apr 2016 12:01:34 +1100 From: Dave Chinner To: Holger =?iso-8859-1?Q?Hoffst=E4tte?= Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCHSET v3][RFC] Make background writeback not suck Message-ID: <20160401010134.GV11812@dastard> References: <1459350477-16404-1-git-send-email-axboe@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 31, 2016 at 10:09:56PM +0000, Holger Hoffstätte wrote: > > Hi, > > Jens mentioned on Twitter I should post my experience here as well, > so here we go. > > I've backported this series (incl. updates) to stable-4.4.x - not too > difficult, minus the NVM part which I don't need anyway - and have been > running it for the past few days without any problem whatsoever, with > GREAT success. > > My use case is primarily larger amounts of stuff (transcoded movies, > finished downloads, built Gentoo packages) that gets copied from tmpfs > to SSD (or disk) and every time that happens, the system noticeably > strangles readers (desktop, interactive shell). It does not really matter > how I tune writeback via the write_expire/dirty_bytes knobs or the > scheduler (and yes, I understand how they work); lowering the writeback > limits helped a bit but the system is still overwhelmed. Jacking up > deadline's writes_starved to unreasonable levels helps a bit, but in turn > makes all writes suffer. Anything else - even tried BFQ for a while, > which has its own unrelated problems - didn't really help either. Can you go back to your original kernel, and lower nr_requests to 8? Essentially all I see the block throttle doing is keeping the request queue depth to somewhere between 8-12 requests, rather than letting it blow out to near nr_requests (around 105-115), so it would be interesting to note whether the block throttling has any noticable difference in behaviour when compared to just having a very shallow request queue.... Cheers, Dave. -- Dave Chinner david@fromorbit.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 1 Apr 2016 12:01:34 +1100 From: Dave Chinner To: Holger =?iso-8859-1?Q?Hoffst=E4tte?= Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCHSET v3][RFC] Make background writeback not suck Message-ID: <20160401010134.GV11812@dastard> References: <1459350477-16404-1-git-send-email-axboe@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: On Thu, Mar 31, 2016 at 10:09:56PM +0000, Holger Hoffst�tte wrote: > > Hi, > > Jens mentioned on Twitter I should post my experience here as well, > so here we go. > > I've backported this series (incl. updates) to stable-4.4.x - not too > difficult, minus the NVM part which I don't need anyway - and have been > running it for the past few days without any problem whatsoever, with > GREAT success. > > My use case is primarily larger amounts of stuff (transcoded movies, > finished downloads, built Gentoo packages) that gets copied from tmpfs > to SSD (or disk) and every time that happens, the system noticeably > strangles readers (desktop, interactive shell). It does not really matter > how I tune writeback via the write_expire/dirty_bytes knobs or the > scheduler (and yes, I understand how they work); lowering the writeback > limits helped a bit but the system is still overwhelmed. Jacking up > deadline's writes_starved to unreasonable levels helps a bit, but in turn > makes all writes suffer. Anything else - even tried BFQ for a while, > which has its own unrelated problems - didn't really help either. Can you go back to your original kernel, and lower nr_requests to 8? Essentially all I see the block throttle doing is keeping the request queue depth to somewhere between 8-12 requests, rather than letting it blow out to near nr_requests (around 105-115), so it would be interesting to note whether the block throttling has any noticable difference in behaviour when compared to just having a very shallow request queue.... Cheers, Dave. -- Dave Chinner david@fromorbit.com