From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751574AbdGZVJa (ORCPT <rfc822;w@1wt.eu>);
        Wed, 26 Jul 2017 17:09:30 -0400
Received: from mail.linuxfoundation.org ([140.211.169.12]:58986 "EHLO
        mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751109AbdGZVJ3 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 26 Jul 2017 17:09:29 -0400
Date: Wed, 26 Jul 2017 14:09:27 -0700
From: Andrew Morton <akpm@linux-foundation.org>
To: Michal Hocko <mhocko@kernel.org>
Cc: Davidlohr Bueso <dave@stgolabs.net>, mingo@kernel.org,
        peterz@infradead.org, jack@suse.cz, torvalds@linux-foundation.org,
        kirill.shutemov@linux.intel.com, hch@infradead.org,
        ldufour@linux.vnet.ibm.com, mgorman@techsingularity.net,
        linux-kernel@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Vladimir Davydov <vdavydov.dev@gmail.com>
Subject: Re: [PATCH 16/17] mem/memcg: cache rightmost node
Message-Id: <20170726140927.1408d4308795d3e3fdb082c4@linux-foundation.org>
In-Reply-To: <20170719075036.GA26779@dhcp22.suse.cz>
References: <20170719014603.19029-1-dave@stgolabs.net>
        <20170719014603.19029-17-dave@stgolabs.net>
        <20170719075036.GA26779@dhcp22.suse.cz>
X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 19 Jul 2017 09:50:36 +0200 Michal Hocko <mhocko@kernel.org> wrote:

> [CC Johannes and Vladimir - the whole series is
> http://lkml.kernel.org/r/20170719014603.19029-1-dave@stgolabs.net]
> 
> On Tue 18-07-17 18:46:02, Davidlohr Bueso wrote:
> > Such that we can optimize __mem_cgroup_largest_soft_limit_node().
> > The only overhead is the extra footprint for the cached pointer,
> > but this should not be an issue for mem_cgroup_tree_per_node.
> 
> The soft limit reclaim and the associated tree manipulation is not worth
> touching/optimizing IMHO. We strongly discourage anybody configuring
> soft limit because of the way how it is implemented and disruptive.

I'm inclined to merge this.  Unless we plan to actually remove the code
"soon", I think it's best to continue to improve it.  Improving
performance may never matter to anyone, but there is benefit in keeping
up to date with the current interfaces and best practices.