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 X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90DA9C55178 for ; Tue, 27 Oct 2020 12:18:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0763C22283 for ; Tue, 27 Oct 2020 12:18:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="aD5eGlPS" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0763C22283 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 90C1C6B007D; Tue, 27 Oct 2020 08:18:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 895226B0080; Tue, 27 Oct 2020 08:18:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 75FA76B0081; Tue, 27 Oct 2020 08:18:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0218.hostedemail.com [216.40.44.218]) by kanga.kvack.org (Postfix) with ESMTP id 41D246B007D for ; Tue, 27 Oct 2020 08:18:23 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id CDC6C1EE6 for ; Tue, 27 Oct 2020 12:18:22 +0000 (UTC) X-FDA: 77417608044.29.wash46_320bf2d2727c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin29.hostedemail.com (Postfix) with ESMTP id AE2D5180868D2 for ; Tue, 27 Oct 2020 12:18:22 +0000 (UTC) X-HE-Tag: wash46_320bf2d2727c X-Filterd-Recvd-Size: 3478 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Tue, 27 Oct 2020 12:18:22 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1603801101; 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: in-reply-to:in-reply-to:references:references; bh=WBz49ARXMK8IVJOaRbIheZJKq8IypKGIjPcbI7hB3Ag=; b=aD5eGlPSmiGuFB3k68ZBviaiz0YEQ2zXE06VKj0H9o5C5z1gXFXy8VIWITYSovvU3RAqZT BYITjE7DRiHtNDdwOnPN2ek5hJsHKl5saEC5UwpnW1rorWDbeFxlKbn1pehJBFetoeTh4L MXHSUDCf4uyYmhawa8ZnXf66MFBQoNQ= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 45E78B30B; Tue, 27 Oct 2020 12:18:20 +0000 (UTC) Date: Tue, 27 Oct 2020 13:18:16 +0100 From: Michal Hocko To: Jann Horn Cc: "Michael Kerrisk (man-pages)" , linux-man , Linux-MM , Mark Mossberg Subject: Re: [PATCH] proc.5: Document inaccurate RSS due to SPLIT_RSS_COUNTING Message-ID: <20201027121816.GS20500@dhcp22.suse.cz> References: <20201012114940.1317510-1-jannh@google.com> <0a090c14-6b70-4284-bb2d-4fbfd1146aaf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Tue 27-10-20 11:35:35, Jann Horn wrote: > On Tue, Oct 27, 2020 at 8:05 AM Michael Kerrisk (man-pages) > wrote: > > On 10/12/20 4:52 PM, Jann Horn wrote: > > > On Mon, Oct 12, 2020 at 1:49 PM Jann Horn wrote: > > >> Since 34e55232e59f7b19050267a05ff1226e5cd122a5 (introduced back in > > >> v2.6.34), Linux uses per-thread RSS counters to reduce cache contention on > > >> the per-mm counters. With a 4K page size, that means that you can end up > > >> with the counters off by up to 252KiB per thread. > > > > > > Actually, as Mark Mossberg pointed out to me off-thread, the counters > > > can actually be off by many times more... > > > > So, does your patch to proc.5 need tweaking, or can I just apply as is? > > The "(up to 63 pages per thread)" would have to go, the rest should be correct. > > But as Michal said, if someone volunteers to get rid of this > optimization, maybe we don't need the documentation after all? But > that would probably require actually doing some careful > heavily-multithreaded benchmarking on a big machine with a few dozen > cores, or something like that, so that we know whether this > optimization actually is unimportant enough that we can just get rid > of it... Well, the original micro optimization didn't really come with some solid numbers based on real workloads. Artificial workloads are likely not very representative for this case because any potential counters overhead normally gets dispersed. I think this is the case where the benefit is so unclear that I would simply revert the whole thing and try to tune up for a real life workloads that actually sees a regression. -- Michal Hocko SUSE Labs