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 DA3C8C369AB for ; Tue, 22 Apr 2025 00:10:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2CA626B0005; Mon, 21 Apr 2025 20:10:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 253B76B0007; Mon, 21 Apr 2025 20:10:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0CCD66B0008; Mon, 21 Apr 2025 20:10:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E1DB06B0005 for ; Mon, 21 Apr 2025 20:10:48 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 40D54BFC51 for ; Tue, 22 Apr 2025 00:10:50 +0000 (UTC) X-FDA: 83359749060.25.BAADA57 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf25.hostedemail.com (Postfix) with ESMTP id 11830A0013 for ; Tue, 22 Apr 2025 00:10:46 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Ktqy0BvR; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf25.hostedemail.com: domain of llong@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=llong@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745280648; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UDtoLS1gBPoKuxtRvVU2gx7fBBeeu41JuptA9opePq4=; b=kAidfzfqurCG6KE3UVOJg/o9845BmjFhbzgHnpiC+w/I/SyG9PA5n4mr1vbC7vWiK3y7OQ sQOwr7rffuBQ/BYEeiU6FKHTl16LFXAM/7BoK9scbfOpkRLm07kH71ORcRbdDq9VzH8cEu Ka1UOjUBpLpjfnO4MYuWw+osHGlU7yI= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Ktqy0BvR; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf25.hostedemail.com: domain of llong@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=llong@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745280648; a=rsa-sha256; cv=none; b=lFwAJCgY0+lObddFT9VcEqW3o2GNIgFYlntNTwL3meGLFmJAsrH/dXdJDQs5ak+Y+o33zX XOIdFZEjjUOEn2j5jUFK+kFN4qfuPUiZCAC/5Y0lSbOVAMShyk74y734eZKMYV7++ANyfG CC8Ij1ieyuvK5kkgOBnGGOc9Mw39Ifc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1745280646; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UDtoLS1gBPoKuxtRvVU2gx7fBBeeu41JuptA9opePq4=; b=Ktqy0BvRCrdEYAqat71lmG/QDukNxDk3EVUN4pSkCOC4qL/IRioGcMWxT+D15NlnjaiZNK bA/3PSNlNR0/rV5jj9b3EzXlCYDYoPgqpDJiKj3tvq3TRd996Nwi0hWEpAnPU2A5UDoviN 40RJ5kiljIf+CxYgmJt+dR9pnA8Ptns= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-232-Izm3u5PXP9izZi9F0HJ2pQ-1; Mon, 21 Apr 2025 20:10:44 -0400 X-MC-Unique: Izm3u5PXP9izZi9F0HJ2pQ-1 X-Mimecast-MFC-AGG-ID: Izm3u5PXP9izZi9F0HJ2pQ_1745280644 Received: by mail-qk1-f200.google.com with SMTP id af79cd13be357-7c549ea7166so664641185a.2 for ; Mon, 21 Apr 2025 17:10:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745280644; x=1745885444; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=UDtoLS1gBPoKuxtRvVU2gx7fBBeeu41JuptA9opePq4=; b=bFy/TTYkRD69rQ+SUn2jvvJvLe59ZRN1ZgolqZpDYblbKpds2fDkDMKDQd8ZfKsOO5 KuZVduSb8+VJnudVR7cvSpG7d5oXS9WHu0IZINycOpvRLTls6uBseSMOr8hXZwpLlND2 YpQpxUNGXz+u602hQwKjRVSZfKdK8tZjxstahPjhU1JSDdaTiVZyOjOBGXHakZSY/d13 Mnz9PkCIXCi6UJH4Ma4AoUEsRz9kCEvOeQ9+vSowCMud0UGRroI89noxiltJjonSVKlj d7EXSuLkLwAc4Rgkja1FpYbpmSOSa/oZz4hX5cAsqrRZMrv/kvoQPCSpWNj7OirKyKgc U8Jg== X-Forwarded-Encrypted: i=1; AJvYcCX0OGxhmGLuvJmSgPJq0iIe8oiNPSmdwgce7qXxk6XAfPAT69FH4IFuDVcCm0oQedqQMVdLjlTDaw==@kvack.org X-Gm-Message-State: AOJu0YwixQid2a0wYlbuRrGPY+pBNjY57cUaU7AppebHSRRJyNEha3/F oFKt00cZlo//kEHjBUuvaTgxHYJuozgDeaGqXOgsKC/aLgPj8P50BzW4NxOBjacXWNp+J4vpLrq NhhTOZkCHiuq64Cg5QS0Ds/zR9ZMCovTpLDGIFCkncx/bgN30 X-Gm-Gg: ASbGncu/pnxA1AxxQ99jXukNnvAzgkjlj2GhXg11TrOhi+tOg8v9GhJeBiXfU80XJxg GZhlkjbs0nL2QiBE4GL2qaqcMD9Z1XiYNAI9I04DOC+59gRCtxeH6zJlPxVwqBBmMmo6iv1k8/G OZfz+Cr9UgI6rr7FEe7m5Ax3Kt+1AcV+4zGitrfCd9ONITzzHmyN/is4iwVWfR/y1Z+JTb0HtDb Wx6eFBz2SrlT+OoC7mQTyPtwBm8jdgRjg+KqcLBZYJkLp8LSC82shACz/2U4soaI63W/HexsGB4 BjhEJ4SiESRy/hfmihlcNiX40Ea+vC9zgnIvnpT23zANtQLn/Pzoku/iEg== X-Received: by 2002:a05:620a:3902:b0:7c8:c97:627f with SMTP id af79cd13be357-7c92803946cmr2242839185a.46.1745280644269; Mon, 21 Apr 2025 17:10:44 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE6cQMQH+I86QARuGvdAqE6cTglxCEoXqyfkreYE8mt033hhYtUssBCdHGEdhmRbI12nDLDRA== X-Received: by 2002:a05:620a:3902:b0:7c8:c97:627f with SMTP id af79cd13be357-7c92803946cmr2242836185a.46.1745280643960; Mon, 21 Apr 2025 17:10:43 -0700 (PDT) Received: from ?IPV6:2601:408:c101:1d00:6621:a07c:fed4:cbba? ([2601:408:c101:1d00:6621:a07c:fed4:cbba]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7c925a8f8c5sm480770885a.44.2025.04.21.17.10.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Apr 2025 17:10:43 -0700 (PDT) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: <3478a69d-b4e9-4561-a09a-d64397ced130@redhat.com> Date: Mon, 21 Apr 2025 20:10:41 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/2] vmscan,cgroup: apply mems_effective to reclaim To: Shakeel Butt , Gregory Price Cc: Waiman Long , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev, muchun.song@linux.dev, tj@kernel.org, mkoutny@suse.com, akpm@linux-foundation.org References: <20250419053824.1601470-1-gourry@gourry.net> <20250419053824.1601470-3-gourry@gourry.net> <7dtp6v5evpz5sdevwrexhwcdtl5enczssvuepkib2oiaexk3oo@ranij7pskrhe> In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: MLkVuYPO11rL6G6kxtHzn9yWTge4tL4pMo11MnpyoWU_1745280644 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: ff3rmbhi4zeuzwfh5drt78e1pzhqbi8s X-Rspamd-Queue-Id: 11830A0013 X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1745280646-731110 X-HE-Meta: U2FsdGVkX18FJ8q+2N5GFmF+MFz3q8TxbEXauMDL7GyqKndZK5w5ARPYdvMqlIv8pAMtnUTgXTFrEBGglAFg5r7mOlpfG3XgPJTsm1mo7ZQPnlp4IYrbNJg1WPLc4Yowg08OPBc6izpi+N5cHdvgchUmgXdaJGB7e11Mo6rC6LoOrVaz7N9eXrwfb52bDCQoWFkWgmlaRwfNmcokguN4Q2G1MvB3FQ8CyGV+Gn/Y8E03cOcnZCFSpdsbCPmwR3/19MngRQLOz9nTmJ8SywVUTfDSYzEFHv7kwupSlLFOzZF8he+5FI78xb0atKwlMyC1GSNXEUj7wQR25HPXUrzFww0JN50aGcab03lmStaOWmB5o7ZqQuu85kxE3PnMg3o5XJ1M7KI7Rh7CiBpy+i+t1X9pReL7P6kx1fJougGWQqD83s5bfxhv+2u+52mCAzGC30VA2kM5mzhErR3yPOJlL4Ui95mfNpkldqZrUVNAItsrkbmuh95eU4ItX4PSmTBmtXIEjexCnaxQpXP7O9jp13gqqGpFDorTmT3pzo6epUOFmY8+OGHvKoxFMztTHf9B6I7Ty51HCDKIgBY3q7Tm3U5mOwHBd0f47y6nmCB7ypHFRG/BxkhsuW3tAmsVlcqEMUytoS3CqVWLd4xstu/GK+fc7He7YPFbgFeziODcY8/l5vcN78CFDxZeWOk8/P7oJtB6StKTAihfBNWRE5UERvGAM+klkOYa35pI9o+AJGlGEEcA9uYPoOMORwQTWPImMGNZa//zItrXT0G68kKwPgCUBwj2Wr6h2V+Ovs6l/Hhr1cjpbEWtMZ1n6uqQ2hxtrOjhSGLR4BXFx9sLpZMEB+V16GuubSudcXwRQB+FESnhXr1myGozKGyhQ+08q0TMMi9cz1t4kzT0DZx6o7WO5ce8pwnYQa8bEAUhH0g58b3jK2kAZ2hU/Hv57RvK0SHKJceNXJYGFxsD2yjVS2y FhGZVGp9 9Ov/vVwhmNjADDw1l6P2CCnrQ5FeNml0ix3eGTt8iqgrnrdOhbazbskMO2+BVK4ZtkTyx2JCdv4mQuBKHMXh51bd/lt6YjTbbuQIvYQ8BVqTgGSe1LRUXSsSyhYMfPMdhQcj3QsFLblplVh6TKpr/eHl5qlcxdDgKaV7jIZst68Kcjp/fj93rciQdwdGcU6aabVxlzF4ReYwooOFwmvbOEXDe3USkKJ6RV5r9oZipJtx1hy2yPzRmDH51h6BnLGkNGy2toIgvI378XhI2IIUhEQ/SHzbncNlLWOTFFd4nFRlWwjxNUErm3bwPjfJUkR/QMYEwym/UHqwSanxZiLAGUh+4nENPabKhx7S7ha17YWV4qDYe06Hc7SSm/w3MUPMnoLdnGLGrYO7U7W/TgAhkNk6YQcZjf5Q15q3J9yMtlsJgCSYyM5Bocd1nTpf+J3+1ykfBme8xUNriP3SGHP05chkR40jHM9dd2hU+ 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: List-Subscribe: List-Unsubscribe: On 4/21/25 7:15 PM, Shakeel Butt wrote: > On Mon, Apr 21, 2025 at 06:59:20PM -0400, Gregory Price wrote: >> On Mon, Apr 21, 2025 at 10:39:58AM -0700, Shakeel Butt wrote: >>> On Sat, Apr 19, 2025 at 08:14:29PM -0400, Waiman Long wrote: >>>> On 4/19/25 2:48 PM, Shakeel Butt wrote: >>>>> On Sat, Apr 19, 2025 at 01:38:24AM -0400, Gregory Price wrote: >>>>>> +bool cpuset_node_allowed(struct cgroup *cgroup, int nid) >>>>>> +{ >>>>>> + struct cgroup_subsys_state *css; >>>>>> + unsigned long flags; >>>>>> + struct cpuset *cs; >>>>>> + bool allowed; >>>>>> + >>>>>> + css = cgroup_get_e_css(cgroup, &cpuset_cgrp_subsys); >>>>>> + if (!css) >>>>>> + return true; >>>>>> + >>>>>> + cs = container_of(css, struct cpuset, css); >>>>>> + spin_lock_irqsave(&callback_lock, flags); >>>>> Do we really need callback_lock here? We are not modifying and I am >>>>> wondering if simple rcu read lock is enough here (similar to >>>>> update_nodemasks_hier() where parent's effective_mems is accessed within >>>>> rcu read lock). >>>> The callback_lock is required to ensure the stability of the effective_mems >>>> which may be in the process of being changed if not taken. >>> Stability in what sense? effective_mems will not get freed under us >>> here or is there a chance for corrupted read here? node_isset() and >>> nodes_empty() seems atomic. What's the worst that can happen without >>> callback_lock? >> Fairly sure nodes_empty is not atomic, it's a bitmap search. > For bitmaps smaller than 64 bits, it seems atomic and MAX_NUMNODES seems > smaller than 64 in all the archs. RHEL sets MAX_NUMNODES to 1024 for x86_64. So it is not really atomic for some distros. In reality, it is rare to have a system with more than 64 nodes (nr_node_ids <= 64). So it can be considered atomic in most cases. > > Anyways I am hoping that we can avoid taking a global lock in reclaim > path which will become a source of contention for memory pressure > situations. It is a valid conern. I will not oppose to checking effective_mems without taking the callback_lock, but we will have to take rcu_read_lock to make sure that the cpuset structure won't go away and clearly document that this is an exceptional case as it is against our usual rule and the check may be incorrect in some rare cases. Cheers, Longman