Received: by 10.223.164.202 with SMTP id h10csp2062921wrb; Fri, 24 Nov 2017 05:24:04 -0800 (PST) X-Google-Smtp-Source: AGs4zMaVcENhOQYre9v3XZtRhHZ/i/K8E0889gVl39+b+orUyfoHMUuSP9DPt/3KkYNR75xMYgZH X-Received: by 10.98.193.1 with SMTP id i1mr261307pfg.29.1511529844456; Fri, 24 Nov 2017 05:24:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511529844; cv=none; d=google.com; s=arc-20160816; b=PyvjxSiiLlNsYwselyqF55VbGjqlbAS7UYSYrEkYZIaZNaze+/GNtwJvBjDyJecDIY UCKhp9JFh0siRtb39xIoH+MM9KROUIM++BoRMMxiiRTWLMbwtqSMplyxfgbJ8U7iYn67 3aeSI3RwtuTndDwHgc93fXElkWE+prAKzsdAmAEq4tBJe+oN4iusmWoKxd/PFAz9jrY1 9phHX8SkOijM6zayjbk5PTEcByLXu9/2gaxm9UUZgcRBHiOvpQ1Bk+wtDdGVFYT0WC4Q BgQH5IMPJQub75o9kIuH3rG80qhNFDEp6NuFrfspmI52nEjNHpzYJAvC1jAuPOKXOgt0 Ni9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=71/5oJGyk48neXLS4Bvyxq1A7ayY/kGxHVtsYZyiJcw=; b=hKZPUkG7lodA5u6FFsNUnk8SQj8/RR2ODSG1F+uP9mTwykedZwXnbrXN/EDaUjpSOu qkCXxl46HYOoHckvA7IHfYgeEXXL+BsYzKaP2DQ2dWaOUOMxNnjT5aH9zWXoLSVzGeK1 33izsNY4SU4SctYWkcXkt+ic4J7ci10OssQ87GwD+fYTnYSASU6FaaPz6zQC+JtsVww9 blEEjvGIAE+9rzLMajvUw31R8GCqC39o+vsfVuWFFt2ENSzeZJzxdBTjKFXG8NtMDQK3 Lrd0ePSTdYUTUDo2oZk+x8cTxyy77Mp0hgNBKQIhlDgJrfFADL1oEipP9fDr/EM9m+aX co2Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b186si17986049pgc.780.2017.11.24.05.23.53; Fri, 24 Nov 2017 05:24:04 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753189AbdKXNXP (ORCPT + 76 others); Fri, 24 Nov 2017 08:23:15 -0500 Received: from jptosegrel01.sonyericsson.com ([124.215.201.71]:16758 "EHLO JPTOSEGREL01.sonyericsson.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752058AbdKXNXM (ORCPT ); Fri, 24 Nov 2017 08:23:12 -0500 X-Greylist: delayed 602 seconds by postgrey-1.27 at vger.kernel.org; Fri, 24 Nov 2017 08:23:12 EST Subject: Re: [PATCH] mm:Add watermark slope for high mark To: Michal Hocko CC: , , , , Jonathan Corbet , "Luis R . Rodriguez" , Kees Cook , Alex Deucher , "David S . Miller" , Harry Wentland , "Greg Kroah-Hartman" , Tony Cheng , David Rientjes , Andrew Morton , Jan Kara , "Kirill A . Shutemov" , Dave Jiang , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Ross Zwisler , Matthew Wilcox , "Hugh Dickins" , Johannes Weiner , Kemi Wang , Vlastimil Babka , YASUAKI ISHIMATSU , Nikolay Borisov , Mel Gorman , Pavel Tatashin , Linux API References: <20171124100707.24190-1-peter.enderborg@sony.com> <20171124101457.by7eoblmk357jwnz@dhcp22.suse.cz> From: peter enderborg Message-ID: <3ff0a870-4a0e-3b8a-ecfd-3db4c6bbd695@sony.com> Date: Fri, 24 Nov 2017 14:12:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171124101457.by7eoblmk357jwnz@dhcp22.suse.cz> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-GB Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/24/2017 11:14 AM, Michal Hocko wrote: > On Fri 24-11-17 11:07:07, Peter Enderborg wrote: >> When tuning the watermark_scale_factor to reduce stalls and compactions >> the high mark is also changed, it changed a bit too much. So this >> patch introduces a slope that can reduce this overhead a bit, or >> increase it if needed. > This doesn't explain what is the problem, why it is a problem and why we > need yet another tuning to address it. Users shouldn't really care about > internal stuff like watermark tuning for each watermark independently. > This looks like a gross hack. Please start over with the problem > description and then we can move on to an approapriate fix. Piling up > tuning knobs to workaround problems is simply not acceptable. > In the original patch - https://lkml.org/lkml/2016/2/18/498 - had a discussion about small systems with 8GB RAM. In the handheld world, that's a lot of RAM. However, the magic number 2 used in the present algorithm is out of the blue. Compaction problems are the same for both small and big. So small devices also need to increase watermark to get compaction to work and reduce direct reclaims. Changing the low watermark makes direct reclaim rate drop a lot. But it will cause kswap to work more, and that has a negative impact. Lowering the gap will smooth out the kswap workload to suite embedded devices a lot better. This can be addressed by reducing the high watermark using the slope patch herein. Im sort of understand your opinion on user knobs, but hard-coded magic numbers are even worse. From 1584943313852457045@xxx Fri Nov 24 10:35:31 +0000 2017 X-GM-THRID: 1584941598460632898 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread