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 307ADEB64D8 for ; Fri, 16 Jun 2023 19:31:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7189F8E0001; Fri, 16 Jun 2023 15:31:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C89A6B0075; Fri, 16 Jun 2023 15:31:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 590488E0001; Fri, 16 Jun 2023 15:31:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 46E976B0074 for ; Fri, 16 Jun 2023 15:31:53 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 873BD160683 for ; Fri, 16 Jun 2023 19:31:50 +0000 (UTC) X-FDA: 80909605980.24.14C22B2 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id 93E2514001A for ; Fri, 16 Jun 2023 19:31:47 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=qjtiRDPG; dmarc=none; spf=pass (imf09.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686943907; 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=w7oMQdkTYR5lt7emioJ4bKdrKD9NAbt60U9Ry9goDdg=; b=cI/mvA+GcbFv8EfN6YRXTWIrJ6qO0G/Y49h17teGdvONWUNVMlwJ7q+fPP7Y5dpYuiAGff 4geNVjoNxourFEqkWJvbwI9tqfUS78dMCPme8khkJ/eFttYecETSXHYPg9cq2oAWqrMqGa wnvW8JHPmkt0Ce4OBlk9tmScP31Tsgc= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=qjtiRDPG; dmarc=none; spf=pass (imf09.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686943907; a=rsa-sha256; cv=none; b=jcyFi0EYlE2Sx2WennwDKPJOUkIaxZznDITh4ei5RwqaUSdZfcl58t2RGu258hvKynJSr7 NjsYBNKw5lBqxA4SsBINfI2PiY6CXeZuxIU8v6mLWLWHxXhs+mqoKDWrUwbGapie1iN+sk hDDy0pKT75RDY0WOeiaPpRd7TpPD69w= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id ABA9B62C02; Fri, 16 Jun 2023 19:31:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 911E3C433C8; Fri, 16 Jun 2023 19:31:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1686943906; bh=KY1WurBWJVnkh28N5jk+SF7UxrRic16Ct16Uf95iD/4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=qjtiRDPGpGU7cNZSie7YNmOLFCFwuHGmzy8IoHjmtjzcgxTHU/LrWNSz69C2LVP78 PvxaE0sfKQXpGGlQtlXV7iDL5pnQSQ2F96YOQV540/T4tw308iYlmvWzy3S0+rmVLE 25I3X0n+RVyGqzApU7VdO8B1UIWIVBIE2EJpzMgo= Date: Fri, 16 Jun 2023 12:31:44 -0700 From: Andrew Morton To: Michal =?UTF-8?B?S291dG7DvQ==?= Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Christian Brauner , Suren Baghdasaryan , "Liam R . Howlett" , Mike Christie , Mathieu Desnoyers , Peter Zijlstra , Nicholas Piggin , Andrei Vagin , Shakeel Butt , Adam Majer , Jan Kara , Michal Hocko Subject: Re: [PATCH] mm: Sync percpu mm RSS counters before querying Message-Id: <20230616123144.bd2a8120dab25736c5c37297@linux-foundation.org> In-Reply-To: <20230616180718.17725-1-mkoutny@suse.com> References: <20230616180718.17725-1-mkoutny@suse.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 93E2514001A X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: kniuzkzsnkn7j3gfoqfk8b7k79f1d5yf X-HE-Tag: 1686943907-672710 X-HE-Meta: U2FsdGVkX1+D844080K1FQ9LXtfjYbFRThuDlrjfjU9VtpY8r7cSqdQRgXYyog9gbOIG3v7+5jpfg+NLmV39Ic96bDL3eZ0IgOk0usKIlLwSlZXcOT+sdC2LUPzlVIXjYt1hpsthlo1tNQFAK067o8yZKaoWdAtUVENY0Ekw+Dv6wGuETTFem7hnw8Dh3K4W3uT3ed1mpaRFM27tGD5KU7Y4tHRH+e4TMpTVlzQqLxESHVBJGaghsEKkFaLZ+whPJmBbeIYQDZOabmw/46A34tIni4Yrcn1jrgw/qUaRaai3b4ifQfggxLyyrKOMbmvi8py5GFB1pYxzcpKyrcmjXZi1pgxhM8D5I41z4n0uBIPsPWxWO/LZ68qzmru1G6FLZIjqW91uxtvSS08ckC5YjX7EQqyKtzDXVUklqZCOr3EPtxlO/+7GXZItd6tiNmxCfb24W4ZWS95X5YdQtrr83JXih1aoVLeeqPF8ltlpu+JMl3lIN2r9gC7fv7/LkcyNf1en+GvuR1gJ2f+lrXXmPAuuIjYNclUpkawsfd7fIW8UBMUIYwZ/+It0YzTQr9cAXhkPSyGMeQTiQ+VJUcP89pmbUrL+HgkrENkfY9V92CoZL2LiU+pz8e7kV6bEE6cCvYPI3+PoSj3Pj2UHyj3/lOBMxti8+JtIZZGRT2q9v++UBHruKttwcQheFdTFHMxbMM1sEJusdr8HJUNzeaixgiF4OXi+E9UD+gBNCk4Nqw6RDA48Yi4s6Z7QmBWqIW77l70lCtJ0taTmUoxLkraBFsqvkj6raKeH22ctLDosG0UpgBezG37p49UPjLaszuk9Y4WRybs+idhTKbzogI95gCeJ3eUfl48Hy0ZEY/V11P0i8kz9PNyWujHwF4tWZ10YJzfqCikNCVzV7UDBUBtxvRMMEjRKL2ZX2GE3t/NEJoYGF5jgssXPmc7AQ8/4oWRv1bZruw8m5zeWxSCs8as 3BGHMZ/1 05GJuM4NA0kr2PEvXOR5uaddEViygNf8sl+JCBKyDvP6bYzVM6PBCEaEB9SI+lxV5vVFtYSn6JgCw38512Grgm/CWRT43pbXmHE7LL249fmJ0NeTmofr6MxaD1ewUNwHKdvxw8cOFieQ83gtZavPfCY6/h60J4OL8j+QoW7MbOjEyA4wxVBMipOm9j17AlYUfbaIK4sZK1Z+V60phevGTMI22/Vl9uyHbfWGxaoS2IMoqx0vtjgEaqBPUDTCzCaLE2y0KNKXmt3G0KAo/k02TMnBePXPaSO+ik4tZcr71P9xg1W0nHxQFkNHlwH1oh/zkDJWCnM7ICsBaqzMQ7O9y8B+c47QVe5r9oQe0I/8IAnnkO7nxW4ziLYu2SuD7ltd4r5jFp/VUcF60tsY= 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 Fri, 16 Jun 2023 20:07:18 +0200 Michal Koutný wrote: > An issue was observed with stats collected in struct rusage on ppc64le > with 64kB pages. The percpu counters use batching with > percpu_counter_batch = max(32, nr*2) # in PAGE_SIZE > i.e. with larger pages but similar RSS consumption (bytes), there'll be > less flushes and error more noticeable. A fully detailed description of the issue would be helpful. Obviously "inaccuracy", but how bad? > In this given case (getting consumption of exited child), we can request > percpu counter's flush without worrying about contention with updaters. > > Fortunately, the commit f1a7941243c1 ("mm: convert mm's rss stats into > percpu_counter") didn't eradicate all traces of SPLIT_RSS_COUNTING and > this mechanism already provided some synchronization points before > reading stats. > Therefore, use sync_mm_rss as carrier for percpu counters refreshes and > forget SPLIT_RSS_COUNTING macro for good. > > Impact of summing on a 8 CPU machine: > Benchmark 1: taskset -c 1 ./shell-bench.sh > > Before > Time (mean ± σ): 9.950 s ± 0.052 s [User: 7.773 s, System: 2.023 s] > > After > Time (mean ± σ): 9.990 s ± 0.070 s [User: 7.825 s, System: 2.011 s] > > cat >shell-bench.sh < for (( i = 0; i < 20000; i++ )); do > /bin/true > done > EOD > > The script is meant to stress fork-exit path (exit is where sync_mm_rss > is most called, add_mm_rss_vec should be covered in fork). > > ... > > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -2547,13 +2547,12 @@ static inline void setmax_mm_hiwater_rss(unsigned long *maxrss, > *maxrss = hiwater_rss; > } > > -#if defined(SPLIT_RSS_COUNTING) > -void sync_mm_rss(struct mm_struct *mm); > -#else > static inline void sync_mm_rss(struct mm_struct *mm) > { > + for (int i = 0; i < NR_MM_COUNTERS; ++i) > + percpu_counter_set(&mm->rss_stat[i], > + percpu_counter_sum(&mm->rss_stat[i])); > } > -#endif Far too large to be inlined! For six callsites it adds 1kb of text. Why even modify the counter? Can't be addressed by using percpu_counter_sum() in an appropriate place? For unknown reasons percpu_counter_set() uses for_each_possible_cpu(). Probably just a mistake - percpu_counters are hotplug-aware and for_each_online_cpu should suffice. I'm really not liking percpu_counter_set(). It's only safe in situations where the caller knows that no other CPU can be modifying the counter. I wonder if all the callers know that. This situation isn't aided by the lack of any documentation.