From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 099E4C2BD09 for ; Tue, 10 Dec 2019 01:20:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D63DB207FF for ; Tue, 10 Dec 2019 01:20:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727448AbfLJBUw (ORCPT ); Mon, 9 Dec 2019 20:20:52 -0500 Received: from mail104.syd.optusnet.com.au ([211.29.132.246]:57265 "EHLO mail104.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727059AbfLJBUw (ORCPT ); Mon, 9 Dec 2019 20:20:52 -0500 Received: from dread.disaster.area (pa49-195-139-249.pa.nsw.optusnet.com.au [49.195.139.249]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 67CED7EA394; Tue, 10 Dec 2019 12:20:37 +1100 (AEDT) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1ieUCa-0006iz-IA; Tue, 10 Dec 2019 12:20:36 +1100 Date: Tue, 10 Dec 2019 12:20:36 +1100 From: Dave Chinner To: Shakeel Butt Cc: Andrey Ryabinin , Pavel Tikhomirov , Andrew Morton , LKML , Cgroups , Linux MM , Johannes Weiner , Michal Hocko , Vladimir Davydov , Roman Gushchin , Chris Down , Yang Shi , Tejun Heo , Thomas Gleixner , "Kirill A . Shutemov" , Konstantin Khorenko , Kirill Tkhai , Trond Myklebust , Anna Schumaker , "J. Bruce Fields" , Chuck Lever , linux-nfs@vger.kernel.org, Alexander Viro , linux-fsdevel Subject: Re: [PATCH] mm: fix hanging shrinker management on long do_shrink_slab Message-ID: <20191210012036.GB19213@dread.disaster.area> References: <20191129214541.3110-1-ptikhomirov@virtuozzo.com> <4e2d959a-0b0e-30aa-59b4-8e37728e9793@virtuozzo.com> <20191206020953.GS2695@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=LYdCFQXi c=1 sm=1 tr=0 a=KoypXv6BqLCQNZUs2nCMWg==:117 a=KoypXv6BqLCQNZUs2nCMWg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=pxVhFHJ0LMsA:10 a=7-415B0cAAAA:8 a=x8hb-4BqU8MrIrHTnBsA:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Fri, Dec 06, 2019 at 09:11:25AM -0800, Shakeel Butt wrote: > On Thu, Dec 5, 2019 at 6:10 PM Dave Chinner wrote: > > If a shrinker is blocking for a long time, then we need to > > work to fix the shrinker implementation because blocking is a much > > bigger problem than just register/unregister. > > > > Yes, we should be fixing the implementations of all shrinkers and yes > it is bigger issue but we can also fix register/unregister isolation > issue in parallel. Fixing all shrinkers would a tedious and long task > and we should not block fixing isolation issue on it. "fixing all shrinkers" is a bit of hyperbole - you've identified only one instance where blocking is causing you problems. Indeed, most shrinkers are already non-blocking and won't cause you any problems at all. > > IOWs, we already know that cycling a global rwsem on every > > individual shrinker invocation is going to cause noticable > > scalability problems. Hence I don't think that this sort of "cycle > > the global rwsem faster to reduce [un]register latency" solution is > > going to fly because of the runtime performance regressions it will > > introduce.... > > > > I agree with your scalability concern (though others would argue to > first demonstrate the issue before adding more sophisticated scalable > code). Look at the git history. We *know* this is a problem, so anyone arguing that we have to prove it can go take a long walk of a short plank.... > Most memory reclaim code is written without the performance or > scalability concern, maybe we should switch our thinking. I think there's a lot of core mm and other developers that would disagree with you there. With respect to shrinkers, we've been directly concerned about performance and scalability of the individual instances as well as the infrastructure for at least the last decade.... Cheers, Dave. -- Dave Chinner david@fromorbit.com