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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48853C433EF for ; Mon, 24 Jan 2022 09:57:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A6D016B0088; Mon, 24 Jan 2022 04:57:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A1CD96B0089; Mon, 24 Jan 2022 04:57:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 90C736B008A; Mon, 24 Jan 2022 04:57:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay026.a.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 7F3F46B0088 for ; Mon, 24 Jan 2022 04:57:43 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 3A3AD227BD for ; Mon, 24 Jan 2022 09:57:43 +0000 (UTC) X-FDA: 79064728806.03.EFD4C11 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf25.hostedemail.com (Postfix) with ESMTP id C415EA0014 for ; Mon, 24 Jan 2022 09:57:42 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 3E93621122; Mon, 24 Jan 2022 09:57:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1643018260; 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=3I0W7aX99uBZEBl2pnVuMlRFfqNgaPY9e+6cid2Tofc=; b=tgNCB7GIulaUwtUgc9fYEchKX7Ic867VG4GAt7BeHL4Dwc2Kw8K2qludbTyCBTK36M0aNF SbgD4jCJ4Fj+eVPnJ4Y36u/gcyE5h5O5BDgBg6eGP7EkutURg2uGdLXZDsEobDOpzwIw9x bR0jKAJs0pGSKOVX4pQZElQ4k27QQOo= 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 08F33A3B81; Mon, 24 Jan 2022 09:57:39 +0000 (UTC) Date: Mon, 24 Jan 2022 10:57:36 +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: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: C415EA0014 X-Stat-Signature: 7frrrtc5ih75yn1ws6euqhzzomi3g3fk Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=tgNCB7GI; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf25.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-HE-Tag: 1643018262-46633 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri 21-01-22 13:56:31, Minchan Kim wrote: > On Fri, Jan 21, 2022 at 10:59:32AM +0100, Michal Hocko wrote: > > 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? > > Couldn't gaurantee whether the IPI is finished with only atomic counter. > > CPU 0 CPU 1 > lru_cache_disable lru_cache_disable > ret = atomic_inc_return > > ret = atomic_inc_return > lru_add_drain_all(ret == 1); lru_add_drain_all(ret == 1) > IPI ongoing skip IPI > alloc_contig_range > fail > .. > .. > > IPI done But __lru_add_drain_all uses a local mutex while the IPI flushing is done so the racing lru_cache_disable would block until flush_work(&per_cpu(lru_add_drain_work, cpu)) completes so all IPIs are handled. Or am I missing something? -- Michal Hocko SUSE Labs