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=-5.2 required=3.0 tests=BAYES_00, 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 C906BC4727F for ; Fri, 2 Oct 2020 08:40:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9875C206B8 for ; Fri, 2 Oct 2020 08:40:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387679AbgJBIks (ORCPT ); Fri, 2 Oct 2020 04:40:48 -0400 Received: from mx2.suse.de ([195.135.220.15]:33462 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725961AbgJBIkp (ORCPT ); Fri, 2 Oct 2020 04:40:45 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 3B40CAE79; Fri, 2 Oct 2020 08:40:44 +0000 (UTC) Date: Fri, 2 Oct 2020 09:40:42 +0100 From: Mel Gorman To: Michal Hocko Cc: Sebastiaan Meijer , akpm@linux-foundation.org, buddy.lumpkin@oracle.com, hannes@cmpxchg.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, riel@surriel.com, willy@infradead.org Subject: Re: [RFC PATCH 1/1] vmscan: Support multiple kswapd threads per node Message-ID: <20201002084042.GB3165@suse.de> References: <20201001123032.GC22560@dhcp22.suse.cz> <20201002070333.GA21871@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20201002070333.GA21871@dhcp22.suse.cz> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 02, 2020 at 09:03:33AM +0200, Michal Hocko wrote: > > > My recollection of the particular patch is dimm but I do remember it > > > tried to add more kswapd threads which would just paper over the problem > > > you are seein rather than solve it. > > > > Yeah, that's exactly what it does, just adding more kswap threads. > > Which is far from trivial because it has its side effects on the over > system balanc. While I have not read the original patches, multiple kswapd threads will smash into the LRU lock repeatedly. It's already the case that just plain storms of page cache allocations hammer that lock on pagevec releases and gets worse as memory sizes increase. Increasing LRU lock contention when memory is low is going to have diminishing returns. -- Mel Gorman SUSE Labs