Received: by 2002:ab2:60d1:0:b0:1f7:5705:b850 with SMTP id i17csp1810514lqm; Fri, 3 May 2024 07:15:03 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCVAMKfyfqur7Xe3Gv0r1dkaY/4MnRqU3qbaWrXxoVTWL0BAgzNuautIgobLj1NN6G0DZt5L0j+JHga3OOsA83kAgpWhMzmCZKYKkGOp5Q== X-Google-Smtp-Source: AGHT+IEXLOgIKfTITF/2RLT7fCed3iEyfhLZE/814LWbPTFeyWO4QhmYvh7owQ0i/5gnEJrPNQkF X-Received: by 2002:a05:6358:7524:b0:183:676f:c751 with SMTP id k36-20020a056358752400b00183676fc751mr2702059rwg.27.1714745702714; Fri, 03 May 2024 07:15:02 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1714745702; cv=pass; d=google.com; s=arc-20160816; b=rB6AhPUwJiUWn/z1IOl8sOwM8QfqyvGwkllMZHOyaW9ff8ilrGjbsXGmNT1xRLDqWS lE6A4Ho58aafn4dpbEi02gMWF6NYMARqlEXOpDDLCKJQ+w27Wja8oORfaIwmYdKwTPSQ 213dDkoGab86oMGCgt99RTAo/swxLXZsUUgQkO5cxiVc56MU1RgBKHDNa8IwfmUwKFZh V1thsvtyJiJ2NOgs/rfc0UDAkRwsaeFnECBqBLAtSxFr+LqdOtA6WySm34NCoQlIWDgt b0uf6+XQM0FdXIgrpowulMrZbpaOgBm5+POV7J4jqnAUpmB9wJBFy5v1mGJB10brhwAa p+iQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=Rs9fMUDcko0mYTl/DxgToWuArkhphaNAoaV6J1pibBU=; fh=etgSs1SjFgjhP+PPTBzLZvFhJVeDrtG1uGQM9CnyGJ4=; b=slg4LFuGOanxXZvLY1Y6r9GmctI5hGh5PD98+bSBwtfqwZ14N8hPv0wBaCJ0BSuCg0 xrydakgXBzjugPAY4saedr0wX621DzMy+Unoqm2dnvTbk2Lg1xXvCMW2RWmm+rZ7aE5/ Tln0KSq9a+u+Yu1QAf40m38DKwNmfRpNq+UwK2D8PGd5WgZggqcAPd1ue9GKS4GLW6ta 4PQp8GJFwiDDUq1MsX+pxYOdy6ej7YaUguL+OyIpLQnYjMBcJm6c5SBBynWMemnB2OmR nzrfxnOXe3irjRM+ggIK0mc+miFOIrB8NI4kRna4sfqCiwCeanCECe89zPelahjWlbl/ LPFA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-167751-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-167751-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id j38-20020a635966000000b005dc4f8a376asi3082239pgm.884.2024.05.03.07.15.02 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 May 2024 07:15:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-167751-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-167751-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-167751-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 3187628445E for ; Fri, 3 May 2024 14:15:02 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3FDE3154BEF; Fri, 3 May 2024 14:14:56 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E6EBF153584 for ; Fri, 3 May 2024 14:14:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714745695; cv=none; b=f4t3yqTgeoGI+valZ9Jw3Ce55Y5Ac0bXNHNoEP4PsxPEvGld5k52Usp8dWmIWuZMGrlsIz4AMFcGEqRuNq2QmjC7pOH/GQY9J1eSaYFcLa28hBDxq0oH7jFgZ5jleIR0O96puIlEhE0PfJjuOerd9WAEitkDnFQRxYlW4Hrp9mc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714745695; c=relaxed/simple; bh=a0miZy6BtS8WlF2l8C6m1AYEuvdLqwVJZpR40YaIV6s=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=CEn2xA21qKGEtFk7DAIDcPCdaxwJ/gZCHw3Sg9vZFYG0GMpsM/v0WCwO9p6Z+23SPLPQBg7KA0MFijA50vrcOsmtUDT3JILULAEOA/4PZjRpYDl8c7Sjm/VUnbh2PSNgqYNecLRd7nJybfoNGxSqFTRTT/4aX6BJJM5ckK3ewTI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 45C7513D5; Fri, 3 May 2024 07:15:17 -0700 (PDT) Received: from [10.57.67.51] (unknown [10.57.67.51]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B180F3F73F; Fri, 3 May 2024 07:14:50 -0700 (PDT) Message-ID: <9d390017-f1c4-44db-864f-cb95b8fd3a9b@arm.com> Date: Fri, 3 May 2024 15:14:49 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] mm/vmstat: sum up all possible CPUs instead of using vm_events_fold_cpu Content-Language: en-GB To: Vlastimil Babka , Barry Song <21cnbao@gmail.com>, akpm@linux-foundation.org, linux-mm@kvack.org Cc: hannes@cmpxchg.org, linux-kernel@vger.kernel.org, david@redhat.com, v-songbaohua@oppo.com, willy@infradead.org References: <20240503020924.208431-1-21cnbao@gmail.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 03/05/2024 14:45, Vlastimil Babka wrote: > On 5/3/24 11:16 AM, Ryan Roberts wrote: >> On 03/05/2024 03:09, Barry Song wrote: >>> @@ -83,8 +83,6 @@ static inline void count_vm_events(enum vm_event_item item, long delta) >>> >>> extern void all_vm_events(unsigned long *); >>> >>> -extern void vm_events_fold_cpu(int cpu); >>> - >>> #else >>> >>> /* Disable counters */ >>> @@ -103,9 +101,6 @@ static inline void __count_vm_events(enum vm_event_item item, long delta) >>> static inline void all_vm_events(unsigned long *ret) >>> { >>> } >>> -static inline void vm_events_fold_cpu(int cpu) >>> -{ >>> -} >>> >>> #endif /* CONFIG_VM_EVENT_COUNTERS */ >>> >>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >>> index cd584aace6bf..8b56d785d587 100644 >>> --- a/mm/page_alloc.c >>> +++ b/mm/page_alloc.c >>> @@ -5826,14 +5826,6 @@ static int page_alloc_cpu_dead(unsigned int cpu) >>> mlock_drain_remote(cpu); >>> drain_pages(cpu); >>> >>> - /* >>> - * Spill the event counters of the dead processor >>> - * into the current processors event counters. >>> - * This artificially elevates the count of the current >>> - * processor. >>> - */ >>> - vm_events_fold_cpu(cpu); >>> - >>> /* >>> * Zero the differential counters of the dead processor >>> * so that the vm statistics are consistent. >>> diff --git a/mm/vmstat.c b/mm/vmstat.c >>> index db79935e4a54..aaa32418652e 100644 >>> --- a/mm/vmstat.c >>> +++ b/mm/vmstat.c >>> @@ -114,7 +114,7 @@ static void sum_vm_events(unsigned long *ret) >>> >>> memset(ret, 0, NR_VM_EVENT_ITEMS * sizeof(unsigned long)); >>> >>> - for_each_online_cpu(cpu) { >>> + for_each_possible_cpu(cpu) { >> >> One thought comes to mind (due to my lack of understanding exactly what >> "possible" means): Linux is compiled with a max number of cpus - NR_CPUS - 512 >> for arm64's defconfig. Does all possible cpus include all 512? On an 8 CPU >> system that would be increasing the number of loops by 64 times. >> >> Or perhaps possible just means CPUs that have ever been online? > > IIRC on x86 it comes from some BIOS tables, and some bioses might be not > providing very realistic numbers, so it can be unnecessary large. OK thanks for the info. > >> Either way, I guess it's not considered a performance bottleneck because, from >> memory, the scheduler and many other places are iterating over all possible cpus. > > I doubt anything does it in a fastpath. But this affects only reading > /proc/vmstat, right? Which is not a fastpath. Also update_balloon_stats() > which is probably ok as well? Yep agreed. > > Either way I don't see a clear advantage nor disadvantage of this. The advantage is just that it deletes 32 lines of code and makes it easier to understand. > >>> struct vm_event_state *this = &per_cpu(vm_event_states, cpu); >>> >>> for (i = 0; i < NR_VM_EVENT_ITEMS; i++) >>> @@ -129,29 +129,10 @@ static void sum_vm_events(unsigned long *ret) >>> */ >>> void all_vm_events(unsigned long *ret) >>> { >>> - cpus_read_lock(); >>> sum_vm_events(ret); >>> - cpus_read_unlock(); >>> } >>> EXPORT_SYMBOL_GPL(all_vm_events); >>> >>> -/* >>> - * Fold the foreign cpu events into our own. >>> - * >>> - * This is adding to the events on one processor >>> - * but keeps the global counts constant. >>> - */ >>> -void vm_events_fold_cpu(int cpu) >>> -{ >>> - struct vm_event_state *fold_state = &per_cpu(vm_event_states, cpu); >>> - int i; >>> - >>> - for (i = 0; i < NR_VM_EVENT_ITEMS; i++) { >>> - count_vm_events(i, fold_state->event[i]); >>> - fold_state->event[i] = 0; >>> - } >>> -} >>> - >>> #endif /* CONFIG_VM_EVENT_COUNTERS */ >>> >>> /* >> >