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=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 7D43AC433E0 for ; Wed, 24 Feb 2021 20:08:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0ED3864EC3 for ; Wed, 24 Feb 2021 20:08:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0ED3864EC3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8F43D8D0048; Wed, 24 Feb 2021 15:08:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8CB6D8D001E; Wed, 24 Feb 2021 15:08:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7E1658D0048; Wed, 24 Feb 2021 15:08:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0223.hostedemail.com [216.40.44.223]) by kanga.kvack.org (Postfix) with ESMTP id 64E888D001E for ; Wed, 24 Feb 2021 15:08:50 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 35099180ACF0E for ; Wed, 24 Feb 2021 20:08:50 +0000 (UTC) X-FDA: 77854249620.01.559DD32 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf13.hostedemail.com (Postfix) with ESMTP id 4FFE4E000118 for ; Wed, 24 Feb 2021 20:08:47 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 5434A64F20; Wed, 24 Feb 2021 20:08:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1614197328; bh=787urpnHfsBgwCqx+7n1DXo2pCIOdY7aT9xYWCKKemQ=; h=Date:From:To:Subject:In-Reply-To:From; b=k3OOA/kGtXegfeV6+K0cAAaTqzkUK9YMGAoHfdagwXjJ/upZge71dn2m88bciVnLi qEQvDtOPsMQDVk677wh7zM+j8Gwe7YvwB9QII+iqzi/Hw1rD3wxMJsNmbgli8dxNNj CdLG57fMLdzZPWM0DBmAUDQSi8WcAjjlb62mTSpI= Date: Wed, 24 Feb 2021 12:08:47 -0800 From: Andrew Morton To: akpm@linux-foundation.org, hannes@cmpxchg.org, linux-mm@kvack.org, mm-commits@vger.kernel.org, osalvador@suse.de, torvalds@linux-foundation.org, vbabka@suse.cz Subject: [patch 145/173] mm: workingset: clarify eviction order and distance calculation Message-ID: <20210224200847.MgJboFbIP%akpm@linux-foundation.org> In-Reply-To: <20210224115824.1e289a6895087f10c41dd8d6@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Stat-Signature: q6fseboutqbyzhwt16hgjnft37cdh3t1 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 4FFE4E000118 Received-SPF: none (linux-foundation.org>: No applicable sender policy available) receiver=imf13; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614197327-489164 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: From: Oscar Salvador Subject: mm: workingset: clarify eviction order and distance calculation The premise of the refault distance is that it can be seen as a deficit of the inactive list space, so that if the inactive list would have had (R - E) more slots, the page would not have been evicted but promoted to the active list instead. However, the way the code is ordered right now set us to be off by one, so the real number of slots would be (R - E) + 1. I stumbled upon this when trying to understand the code and it puzzled me that the comments did not match what the code did. This it not an issue at all since evictions and refaults tend to happen in a number large enough that being off-by-one does not have any impact - and since the compiler and CPUs are free to rearrange the execution sequence anyway. But as Johannes says, it is better to re-arrange the code in the proper order since otherwise would be misleading to somebody who is actively reading and trying to understand the logic of the code - like it happened to me. Link: https://lkml.kernel.org/r/20210201060651.3781-1-osalvador@suse.de Signed-off-by: Oscar Salvador Acked-by: Johannes Weiner Acked-by: Vlastimil Babka Signed-off-by: Andrew Morton --- mm/workingset.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/workingset.c~mm-workingset-clarify-eviction-order-and-distance-calculation +++ a/mm/workingset.c @@ -263,10 +263,10 @@ void *workingset_eviction(struct page *p VM_BUG_ON_PAGE(!PageLocked(page), page); lruvec = mem_cgroup_lruvec(target_memcg, pgdat); - workingset_age_nonresident(lruvec, thp_nr_pages(page)); /* XXX: target_memcg can be NULL, go through lruvec */ memcgid = mem_cgroup_id(lruvec_memcg(lruvec)); eviction = atomic_long_read(&lruvec->nonresident_age); + workingset_age_nonresident(lruvec, thp_nr_pages(page)); return pack_shadow(memcgid, pgdat, eviction, PageWorkingset(page)); } _