From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A87F03CDBC4 for ; Mon, 29 Jun 2026 23:16:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782774998; cv=none; b=nDBU1sjbe7wZdUQOKpWMFJui38y6mCM9qxJ/7baaAPChPFyBk2lkkj5LGqchI7PlaPR4Pc+gHhzhizA3OVJnDTuNir6AuPcsFMV/Se3jzmi1w6sQZjADhCIvVSeicLHJUGMkxIYX53F2Eyt6FWPZBkyYJiXHDQHRANvX8uVyqro= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782774998; c=relaxed/simple; bh=1I8wND6YjmvdO9vSy35X5XmDr6a1qzt112d5mvUweGM=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=TyRtAhdf5rg6jqJZvgj4RXJi5oGQHbTjpSK1+KPMwRJEan2bwWL6o0lviQaHLiRs7yqpRXYJZOEVqke/HX60D2uKkqMV6I2Z3i6wbzN3z/kW0f8voZ73KQv6CVyDcU7WJr6fjq4WWwikJFSuSw8QpuPaO7OEYPZVJ81R33IPIlI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hzbYVWzU; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hzbYVWzU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 594C41F00ADF for ; Mon, 29 Jun 2026 23:16:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782774997; bh=5hC0X9bJ6J8UVZ393AJBN7jBUEho3jUulgQn9n8X4TM=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=hzbYVWzUEXW/HMHT8ZKayKHOoQjeXW55WYPqAB0KYFQscyQJgLajySVSL08sYvHPv APmR7RDbRK9jKGDbVQz/UM/QpnL+AhzTS7L0j2EugmHtwefvUqae0m83iSpuBAg+dP HIFuQOzzRL97m85UH8HN6KDftqYxyvPYqybdzvHYHK5XQx0EjlU7XEhc+Oo/HTgTzJ 53DkNldx5PDtD8jiEWjFJaCUblngEVmbjtEwyoNZ2+yEzPodrhbduwS3yYlXV2043D uk+EU9994XdYkhi1SVKQ2DRl0HlmiazNI2R23Yg7h7QyJ+TJ7kIkNnWoIkKw6YR2cX uEH1ZRbMIzB1A== Received: by mail-qv1-f48.google.com with SMTP id 6a1803df08f44-8eec5dfdb65so11600236d6.0 for ; Mon, 29 Jun 2026 16:16:37 -0700 (PDT) X-Forwarded-Encrypted: i=1; AHgh+Roj2RpZUY3fnai0hv7mhh+hJjW4qnMDKemgh/U2b+Q123csYibXHElV3x5smKN848WswCd4keAjeZaC+cE=@vger.kernel.org X-Gm-Message-State: AOJu0YxnBPpXTYlrl/SW/6Hfo77oY49agZg+300LVTH2J3Be8TolOOJh xd3rlN8KSvs6dktCNlpVyvz5GGwlpJHR0uPEvzShLLx33s/s+KBwfB1H2o6V6+KWM0cBp1VlABT RUOvMUcwJQtjTfAiuAob4zt6tURVEoRA= X-Received: by 2002:a05:6214:f61:b0:8df:10fd:93f with SMTP id 6a1803df08f44-8f1b96231a1mr23810586d6.12.1782774996525; Mon, 29 Jun 2026 16:16:36 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260623231635.43086-1-baohua@kernel.org> <20260623231635.43086-2-baohua@kernel.org> <3903def5-e823-4fe3-9784-b6bd63470516@kernel.org> In-Reply-To: <3903def5-e823-4fe3-9784-b6bd63470516@kernel.org> From: Barry Song Date: Tue, 30 Jun 2026 07:16:24 +0800 X-Gmail-Original-Message-ID: X-Gm-Features: AVVi8Cd_505qbOkAcy1kTaKFVxeIIoncNKknSMEiUclL8Mi6Dv6K1Ix7aCzLEOo Message-ID: Subject: Re: [PATCH v2 1/4] mm: avoid unnecessary lru drain for wp_can_reuse_anon_folio() To: "David Hildenbrand (Arm)" Cc: Shakeel Butt , akpm@linux-foundation.org, linux-mm@kvack.org, baoquan.he@linux.dev, chrisl@kernel.org, jp.kobryn@linux.dev, kasong@tencent.com, liam@infradead.org, linux-kernel@vger.kernel.org, ljs@kernel.org, mhocko@suse.com, nphamcs@gmail.com, rppt@kernel.org, shikemeng@huaweicloud.com, surenb@google.com, usama.arif@linux.dev, vbabka@kernel.org, youngjun.park@lge.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 29, 2026 at 3:52=E2=80=AFPM David Hildenbrand (Arm) wrote: [...] > > So yeah, if Nadav's reproducer works even without the drain (which I assu= me), we > could indeed think about just removing this optimization here. Yet I think the problem is resolved with the exclusive flag. Right now, we can still have cases where "exclusive" cannot address it, such as: #include int main(int argc, char *argv[]) { int i; #define SIZE 30*1024*1024 while(1) { volatile int *p =3D mmap(0, SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); volatile int q; for (int i =3D 0; i < SIZE/sizeof(int); i++) p[i] =3D i; madvise((void *)p, SIZE, MADV_PAGEOUT); if (!fork()) _exit(0); for (int i =3D 0; i < SIZE/sizeof(int); i++) q =3D p[i]; for (int i =3D 0; i < SIZE/sizeof(int); i++) p[i] =3D i; munmap(p, SIZE); } return 0; } I assume this is less frequent and less of a concern? Thanks Barry