From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 574971FB3 for ; Fri, 27 Dec 2024 15:49:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735314582; cv=none; b=Q/A1Gqb1Ge+/IMP23nhaB758RyRxlYS7N5SoPEfcYJipfgTACjzArU8y5hkXfw1W2zVe3AHqKIlbJd1HtVcO0ZHvwB7Dih82G0CP6PaOhrnL1vdFfLRHCoJfXtoSSHtxr97Fx9vl3pLLceOJ0arKU0xhC0rqAuafQtWFLAb8xHE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735314582; c=relaxed/simple; bh=3KOYjdv8WovS5TIlt/uTa7on4XP9tpvhgFYHZlxV8S0=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EvsSoDst4ZGCXu4NwiUE/HA25YUFP7CY59EjPJXQ4m5YyHmO1XHunAfFAg20wtTK6qrEa0zQPeLXde76ofkfdkjH6jsHyKvnAXQHHTjxnl8FKXzWFL+M1DRLkVi0CjdnKvlv6qEDvP/2rFC92gg1FW6Hs4zfBZJ5Do5ueR2wMYc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=kr2RwVf1; arc=none smtp.client-ip=209.85.222.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="kr2RwVf1" Received: by mail-qk1-f170.google.com with SMTP id af79cd13be357-7b702c3c021so627361385a.3 for ; Fri, 27 Dec 2024 07:49:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1735314579; x=1735919379; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=4UOU6oWextV2G+tUTB+1mr03GjM/WyWFtMHRRkOsfTU=; b=kr2RwVf1+ewmTJb1bzAt9Zjji9j+dfrTIQiuwma4nJN8DAwgxfsU1Ann4I5MlS1zXU FTbbA60f0F7FtKaeS+6EHuioPXcOm1zOHGHf3mTwyYvOifjZKVXKfduk+cYagX4jIk0q D3LG1pWWrbqQ5Fw7fYyyWHjoHkiD8O1fU74jOVHXMlr9rWEkK6QKElUq1f+VI2sbWyTc aObORiO0MJfSjl0/oUIYZ+9UPoWwMhFQ6de/NEmA3iay2TAwo1T+54F5EOGYq74iJRc1 hpOa3zNQMOYKCMNICwFcqs4XoBu95CEvLWk1IAirb104k93WOB8BrQ5nRUKYxzb92F38 36dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735314579; x=1735919379; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4UOU6oWextV2G+tUTB+1mr03GjM/WyWFtMHRRkOsfTU=; b=rNxnPaKqXGHN57lxo6ildBn7jIulLLnBGRBKi0s+MwG+H70WPt4dTfzYHJ5+WF67+4 tdm8l3uD+7pUH2q4P7sYAByfXNDDwb65UUcxo+yzGVJwsUNJAS+LiFm/RhKpPU2epSmu ZlRAr6T3/c+ZGoIMAFJ+kt5ejH/47h5QO77aC9EjeGywQfXFjN3a3CfnHDQx0RyOGn/i hB7Qnu+lHyMRtILeKMjDszByJQbQQMwb5AumCQB0njkiykzT/QyMi59/UW9LLHWLngiX NSGlzNghrKFEeN6MDm8VmGYXC5hoFg8hd79C2TjQDilquBuzM3lmCKXxmSEJXjhEMy+v qXkA== X-Forwarded-Encrypted: i=1; AJvYcCX1jr2xCIblGKU9Vh5zmUAys/rrVWoWAA6mOnZyu+Vvi4MdcO3Pe/DiKN7sO1QaP84iCIy776osOsBqhJA=@vger.kernel.org X-Gm-Message-State: AOJu0YyKhFDd4ccdulGkwEDUu1ki2n1cZFznxu6duYx4pKu/Krui6LB3 7Rf1wOoH1KNsyA/xSLUJnbpq0vMpobZSRg8QT3HCucd6ZaICfEGrHyIDOtfsqtw= X-Gm-Gg: ASbGncvAelTBeojptLRvPsPgZgZ29DC6vBv4V86PTZKcueeZHlGQPIFjDppeB0bLeYL vFtZeriaQ8ib9p2b6KfVIM4Ph2u60D2YtkHEAnFLgLA3B4idHvCE5iR7YEYWJx5uCa1MxpEGMEA Wd0R0gGbuWKAob3hQFb2psQ7cela6BhrljDyL9dHxzyi14KaJMaQ7bXTpHFlFbAj0bwLhItHB9H 2/IvkRs6PkRYz2uBdogCBTZuRR6RuM4Inns2Wh6bR5FgBJB75Ba3GHFVYdDnBKwtjrkhS7mMtGk l5I89RiaIecDj7a5te37tyJZ5iqiMmDeoRzcfyhKxd8r8Ui1NyrRhDA= X-Google-Smtp-Source: AGHT+IHT0Ulq+soX8EHJOQDzDKMjCxLBpAXhwtbTu+KTS/F1WjF4MyTA+x0YrC5N503P3jgZK8Xibw== X-Received: by 2002:a05:620a:1792:b0:7b6:f17d:f5a7 with SMTP id af79cd13be357-7b9ba716fc4mr4258800485a.6.1735314579366; Fri, 27 Dec 2024 07:49:39 -0800 (PST) Received: from gourry-fedora-PF4VCD3F (pool-173-79-56-208.washdc.fios.verizon.net. [173.79.56.208]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7b9ac2bd995sm708597085a.21.2024.12.27.07.49.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Dec 2024 07:49:38 -0800 (PST) From: Gregory Price X-Google-Original-From: Gregory Price Date: Fri, 27 Dec 2024 10:49:37 -0500 To: Donet Tom Cc: Gregory Price , linux-mm@kvack.org, linux-kernel@vger.kernel.org, nehagholkar@meta.com, abhishekd@meta.com, kernel-team@meta.com, david@redhat.com, nphamcs@gmail.com, akpm@linux-foundation.org, hannes@cmpxchg.org, kbusch@meta.com, ying.huang@linux.alibaba.com Subject: Re: [RFC v2 PATCH 4/5] vmstat: add page-cache numa hints Message-ID: References: <20241210213744.2968-1-gourry@gourry.net> <20241210213744.2968-5-gourry@gourry.net> <4504da8d-a5e7-45a1-9feb-167f94210200@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4504da8d-a5e7-45a1-9feb-167f94210200@linux.ibm.com> On Fri, Dec 27, 2024 at 04:18:24PM +0530, Donet Tom wrote: > > On 12/11/24 03:07, Gregory Price wrote: ... snip ... > > + NUMA_HINT_PAGE_CACHE, > > + NUMA_HINT_PAGE_CACHE_LOCAL, > > NUMA_PAGE_MIGRATE, ... snip ... > > if (folio_nid(folio) == numa_node_id()) { > > - count_vm_numa_event(NUMA_HINT_FAULTS_LOCAL); > > + count_vm_numa_event(NUMA_HINT_TYPE_LOCAL(vmf)); > > I have tested this patch series on my system with my test program. I am able > to see unmapped page cache pages are getting promoted. > numa_hint_faults2269numa_hint_faults_local2245numa_hint_page_cache1244numa_hint_page_cache_local0numa_pages_migrated4501 > > In my test result numa_hint_page_cache_local is 0. I am seeing > numa_hint_page_cache_local will only be incremented if the folio's > node and the process's running node are the same. This condition > does not occur in the current implementation, correct? > I did not want to assume we'd never use this interface where such a scenario could occur - so i wanted to: a) make such a scenario visible b) make the code consistent with existing fault counts I'm fine removing it. It's hard to know if this interface ever gets called with that scenario occurringwithout capturing the data. ~Gregory