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 4F2DCC433EF for ; Thu, 20 Jan 2022 21:08:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 925B96B0072; Thu, 20 Jan 2022 16:07:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8AF0E6B0074; Thu, 20 Jan 2022 16:07:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 74EDD6B007E; Thu, 20 Jan 2022 16:07:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0188.hostedemail.com [216.40.44.188]) by kanga.kvack.org (Postfix) with ESMTP id 6321D6B0072 for ; Thu, 20 Jan 2022 16:07:59 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 22DDF824C42F for ; Thu, 20 Jan 2022 21:07:59 +0000 (UTC) X-FDA: 79051902678.11.A4750DF Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) by imf04.hostedemail.com (Postfix) with ESMTP id A8B764000E for ; Thu, 20 Jan 2022 21:07:58 +0000 (UTC) Received: by mail-pg1-f178.google.com with SMTP id c5so6317272pgk.12 for ; Thu, 20 Jan 2022 13:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=7yReEIG2XuZiaNevYXoaZDowK53Ixw5WTV91sPdZZqQ=; b=grI/nQxFj4oq2UTCiTdXevZ8OZsVAsxw2JnG3XbEjojLZnobinLSlHnGgZLO52pCZI 19THJqzHoFwydtdyad18RY2vhUe/8mJU5w3B7O5rQOcLM5Zjh2qeZ1Ho4BlWsW2vk03n E4Cf0jadhAew4LxhZo3sl6KLyG5ePdu9lHc8dHnNkfpu/xSRs5Ih7ARPmIP1OjHbrfmz a3lp3vsNO1gd7m57yEEz8KmT4O9sAzSRaZNzkATJ4RTqzuynqEpiyEkXlIT8Mxkje8mZ BxHNBSIzmA36MR4Zbt/uqRq7DWfg5Zaoc1WmBkQrjac1U3F1Lfr7E+6BFTjd/lopnPdc 231w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=7yReEIG2XuZiaNevYXoaZDowK53Ixw5WTV91sPdZZqQ=; b=uDFgHDmhiQ2Q3mD1Ay2xOgFZ0qMjMXzCghj6PgOTZWIgjrzB0iAv2hcmhssaR718sj 87k0PP0+RMqaUUm0rsx3pyeBAkemOxkTWE89Hqgdt2U/hTZfmL37V8N5ekIuw2QvVMb7 Qb32kNCBboed2mbSZtFVNLOI0V2t1RykNOmRwQjxrDPFBXGPLIKI+PbkaciqnJMyZdEs Pym4nErfbnMNfch7Atjz5JxD4pnK7KHaMsRkj1B43YbozosJ76YIy6nWPwqzqncYK0Ga pC21UZXGvKZ8MchWDQrS7I9f7w/zCNJtzhccLLdJtu8DN9rfrQLnWNFrtdpauIQeaM8W kSMA== X-Gm-Message-State: AOAM532rx2omoeOAPBeI4fXbWmw38vNzvX1aMbmuOSdHHSPy+A2VvMv4 AvYItN5hLanyPHCRe1Z4dVs= X-Google-Smtp-Source: ABdhPJyDsV/Dackn7ETE8gQmoorS0gE8B+qtyYaosDeMdlIlb4q1K/lzMrYQ09g8a7ycDinULfPXxA== X-Received: by 2002:a63:2210:: with SMTP id i16mr488618pgi.532.1642712877626; Thu, 20 Jan 2022 13:07:57 -0800 (PST) Received: from google.com ([2620:15c:211:201:b370:1e12:5bf4:801f]) by smtp.gmail.com with ESMTPSA id h21sm4549939pfh.93.2022.01.20.13.07.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Jan 2022 13:07:57 -0800 (PST) Date: Thu, 20 Jan 2022 13:07:55 -0800 From: Minchan Kim To: Michal Hocko 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-Queue-Id: A8B764000E X-Stat-Signature: h7qgfnb4437zgco51ybf4xagp5mst56j Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="grI/nQxF"; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf04.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.215.178 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com X-Rspamd-Server: rspam02 X-HE-Tag: 1642712878-418230 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 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.