From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755910AbcHTBIe (ORCPT ); Fri, 19 Aug 2016 21:08:34 -0400 Received: from mail-oi0-f66.google.com ([209.85.218.66]:36494 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755619AbcHTBIQ (ORCPT ); Fri, 19 Aug 2016 21:08:16 -0400 MIME-Version: 1.0 In-Reply-To: <20160819234839.GG22388@dastard> References: <20160816150500.GH8119@techsingularity.net> <20160817154907.GI8119@techsingularity.net> <20160818004517.GJ8119@techsingularity.net> <20160818071111.GD22388@dastard> <20160818132414.GK8119@techsingularity.net> <20160818211949.GE22388@dastard> <20160819104946.GL8119@techsingularity.net> <20160819234839.GG22388@dastard> From: Linus Torvalds Date: Fri, 19 Aug 2016 18:08:00 -0700 X-Google-Sender-Auth: Kk7inDHrGz6expwNO_EDknpRExo Message-ID: Subject: Re: [LKP] [lkp] [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression To: Dave Chinner Cc: Mel Gorman , Michal Hocko , Minchan Kim , Vladimir Davydov , Johannes Weiner , Vlastimil Babka , Andrew Morton , Bob Peterson , "Kirill A. Shutemov" , "Huang, Ying" , Christoph Hellwig , Wu Fengguang , LKP , Tejun Heo , LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 19, 2016 at 4:48 PM, Dave Chinner wrote: > > Well, it depends on the speed of the storage. The higher the speed > of the storage, the less we care about stalling on dirty pages > during reclaim Actually, that's largely true independently of the speed of the storage, I feel. On really fast storage, you might as well push it out and buffering lots of dirty memory pointless. And on really slow storage, buffering lots of dirty memory is absolutely *horrible* from a latency standpoint. So I don't think this is about fast-vs-slow disks. I think a lot of our "let's aggressively buffer dirty data" is entirely historical. When you had 16MB of RAM in a workstation, aggressively using half of it for writeback caches meant that you could do things like untar source trees without waiting for IO. But when you have 16GB of RAM in a workstation, and terabytes of RAM in multi-node big machines, it's kind of silly to talk about "percentages of memory available" for dirty data. I think it's likely silly to even see "one node worth of memory" as being some limiter. So I think we should try to avoid stalling on dirty pages during reclaim by simply aiming to have fewer dirty pages in the first place. Not because the stall is shorter on a fast disk, but because we just shouldn't use that much memory for dirty data. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============7765950862993693286==" MIME-Version: 1.0 From: Linus Torvalds To: lkp@lists.01.org Subject: Re: [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression Date: Fri, 19 Aug 2016 18:08:00 -0700 Message-ID: In-Reply-To: <20160819234839.GG22388@dastard> List-Id: --===============7765950862993693286== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Fri, Aug 19, 2016 at 4:48 PM, Dave Chinner wrote: > > Well, it depends on the speed of the storage. The higher the speed > of the storage, the less we care about stalling on dirty pages > during reclaim Actually, that's largely true independently of the speed of the storage, I = feel. On really fast storage, you might as well push it out and buffering lots of dirty memory pointless. And on really slow storage, buffering lots of dirty memory is absolutely *horrible* from a latency standpoint. So I don't think this is about fast-vs-slow disks. I think a lot of our "let's aggressively buffer dirty data" is entirely historical. When you had 16MB of RAM in a workstation, aggressively using half of it for writeback caches meant that you could do things like untar source trees without waiting for IO. But when you have 16GB of RAM in a workstation, and terabytes of RAM in multi-node big machines, it's kind of silly to talk about "percentages of memory available" for dirty data. I think it's likely silly to even see "one node worth of memory" as being some limiter. So I think we should try to avoid stalling on dirty pages during reclaim by simply aiming to have fewer dirty pages in the first place. Not because the stall is shorter on a fast disk, but because we just shouldn't use that much memory for dirty data. Linus --===============7765950862993693286==--