Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp1369824pxb; Fri, 21 Jan 2022 16:45:55 -0800 (PST) X-Google-Smtp-Source: ABdhPJwQWiwqtzHC5LbCQPrC8x/fRwHpXrbdQ8rE0e6u0cw9s2zeGm/KzmvmM9f4rHd8645WmyKO X-Received: by 2002:a17:902:8ec5:b0:149:d41a:baa8 with SMTP id x5-20020a1709028ec500b00149d41abaa8mr5691130plo.115.1642812355797; Fri, 21 Jan 2022 16:45:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642812355; cv=none; d=google.com; s=arc-20160816; b=lWpzIaUXpUms2QMf5ZgqK4tRZY8/khYwj7r5i5lD01iRH2ZfnZE60xDJgQevqcdLj7 8iDCXz1uULD3tSfx8xs1X3aCm1rf+6fFoV+cJ1lmIG+zWidO0ezvu8oXW2h7UR4vn79S 5HdUXDqsG9+SwQb1HwkovRljMgtbu+oJtxngJlVcPymFB/dhCOp4sUMIQAU5AMRzWq7O fz0D/+Nt0PUgFnu8hc9PYf1hHTf9+H+eaFZAJyVMjO+f6F7nsEemApC3o/XQLZfcaR2n VC02lhCCr+LSPPOJHfUgRSSLnvRIy4B6TbmwyzRNiv3c+STMeSTDCRgYxt096Uu+lZov 5FCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=txiYfsB/ZVqu58YnbSCKgoimsE8JyGRSMKIcL+DqcGI=; b=SW3P2UyiFoFHfQ93eTZSKag7QQMcJdI3Sxy9x3yDUQQVV+ZKY9PcW/Ty/2OJGvgiTG KZR9Fv2qKN+TMtbUX6CgAw2nnKIrsxDwH67pwTYzgoZ1df/HYCQ2YnSkTZS4cj0TgaNv +vl2XSN0UEjb1uljUM79m1YPGC13HIdV274t7Ro0PgoHur8Go32sD33+PXNWLC6K6rlZ 61+DYBgGSqwArG8giJ8GtBPZHfGxyfEGxRtF04j3+xXJnXwVjP3buWxdGabgXXFHQlkx ScVWllENKb4z7k2KHfNplw8Marf5QUzIDE26A3+Zv60pPgu1WG3a0oSdjIdAoNUBe0A5 gNPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=HfMrRPy2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=suse.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h20si7061328pfn.59.2022.01.21.16.45.44; Fri, 21 Jan 2022 16:45:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=HfMrRPy2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1379821AbiAUJ7e (ORCPT + 99 others); Fri, 21 Jan 2022 04:59:34 -0500 Received: from smtp-out1.suse.de ([195.135.220.28]:43128 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344496AbiAUJ7d (ORCPT ); Fri, 21 Jan 2022 04:59:33 -0500 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id BE759218F2; Fri, 21 Jan 2022 09:59:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1642759172; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=txiYfsB/ZVqu58YnbSCKgoimsE8JyGRSMKIcL+DqcGI=; b=HfMrRPy22TTfIzSpCw+4rvFV1Sbedi3V+LmXQCxD4mrGRQSXb3SnyhKTtdueDKwKN8LVra jLMHb7R2tAXxAUNO1oaISGsRDakBhsSzN8odIjsFBnSfpJ8nnCHYhchHzkFObPKWE6hzO+ spfazkDYV4auClYRPFxDSBZsOrRx5Aw= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id A8F96A3BA2; Fri, 21 Jan 2022 09:59:32 +0000 (UTC) Date: Fri, 21 Jan 2022 10:59:32 +0100 From: Michal Hocko To: Minchan Kim Cc: Andrew Morton , David Hildenbrand , linux-mm , LKML , Suren Baghdasaryan , John Dias Subject: Re: [RESEND][PATCH v2] mm: don't call lru draining in the nested lru_cache_disable Message-ID: References: <20211230193627.495145-1-minchan@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 20-01-22 13:07:55, Minchan Kim wrote: > On Thu, Jan 20, 2022 at 09:24:22AM +0100, Michal Hocko wrote: > > On Wed 19-01-22 20:25:54, Minchan Kim wrote: > > > On Wed, Jan 19, 2022 at 10:20:22AM +0100, Michal Hocko wrote: > > [...] > > > > What does prevent you from calling lru_cache_{disable,enable} this way > > > > with the existing implementation? AFAICS calls can be nested just fine. > > > > Or am I missing something? > > > > > > It just increases more IPI calls since we drain the lru cache > > > both upper layer and lower layer. That's I'd like to avoid > > > in this patch. Just disable lru cache one time for entire > > > allocation path. > > > > I do not follow. Once you call lru_cache_disable at the higher level > > then no new pages are going to be added to the pcp caches. At the same > > time existing caches are flushed so the inner lru_cache_disable will not > > trigger any new IPIs. > > lru_cache_disable calls __lru_add_drain_all with force_all_cpus > unconditionally so keep calling the IPI. OK, this is something I have missed. Why cannot we remove the force_all mode for lru_disable_count>0 when there are no pcp caches populated? -- Michal Hocko SUSE Labs