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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 3BA91C5DF60 for ; Wed, 6 Nov 2019 00:29:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C7F1B2087E for ; Wed, 6 Nov 2019 00:29:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C7F1B2087E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8885C6B0003; Tue, 5 Nov 2019 19:29:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 839096B0005; Tue, 5 Nov 2019 19:29:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 727D46B0007; Tue, 5 Nov 2019 19:29:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0006.hostedemail.com [216.40.44.6]) by kanga.kvack.org (Postfix) with ESMTP id 5135C6B0003 for ; Tue, 5 Nov 2019 19:29:08 -0500 (EST) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 069C6181AEF10 for ; Wed, 6 Nov 2019 00:29:08 +0000 (UTC) X-FDA: 76123967976.07.low97_157256e54e24f X-HE-Tag: low97_157256e54e24f X-Filterd-Recvd-Size: 4669 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Wed, 6 Nov 2019 00:29:07 +0000 (UTC) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Nov 2019 16:29:05 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,271,1569308400"; d="scan'208";a="285496337" Received: from richard.sh.intel.com (HELO localhost) ([10.239.159.54]) by orsmga001.jf.intel.com with ESMTP; 05 Nov 2019 16:29:03 -0800 Date: Wed, 6 Nov 2019 08:28:50 +0800 From: Wei Yang To: Hugh Dickins Cc: Vlastimil Babka , Wei Yang , Matthew Wilcox , linux-mm@kvack.org, "Kirill A. Shutemov" , Roman Gushchin , Minchan Kim , Kirill Tkhai Subject: Re: Why sometimes count vm event with page number, sometimes not? Message-ID: <20191106002850.GA8745@richard> Reply-To: Wei Yang References: <20191105022643.GA14722@richard> <20191105033251.GB11823@bombadil.infradead.org> <20191105062809.GA15848@richard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Nov 05, 2019 at 12:49:17PM -0800, Hugh Dickins wrote: >On Tue, 5 Nov 2019, Vlastimil Babka wrote: >> On 11/5/19 7:28 AM, Wei Yang wrote: >> > On Mon, Nov 04, 2019 at 07:32:51PM -0800, Matthew Wilcox wrote: >> >> On Tue, Nov 05, 2019 at 10:26:44AM +0800, Wei Yang wrote: >> >>> Hi, All, >> >>> >> >>> I am curious about the semantic of __count_vm_event[s]. >> >>> >> >>> For example, we count PGDEACTIVATE event in lru_deactivate_file_fn() and >> >>> lru_deactivate_fn(). One of them count with number of page, the other not. >> >>> >> >>> Just curious about the exact value we want to count. >> >> >> >> I don't understand the question. We deactivate one page >> >> in lru_deactivate_file_fn(). We deactivate several pages in >> >> shrink_active_list(). PGDEACTIVATE counts the number of pages which >> >> have been deactivated. >> >> >> >> Does that answer your question? >> > >> > Not yet. >> > >> > In function, lru_deactivate_fn(), __count_vm_events's second parameter is >> > hpage_nr_pages(page). This is the number in size of "normal" page. Per my >> > understanding, the page deactivated in lru_deactivate_file_fn() could be a >> > hpage too. But it just count the deactivation once instead of >> > hpage_nr_pages(). >> > >> > Or you want to say the page deactivated in lru_deactivate_file_fn() must be an >> > order 0 page? >> >> I suspect that was true before THP on shmem, but now perhaps it's not >> true anymore? CCing Kirill and Hugh. > >I think that you and Wei are right, that lru_deactivate_file_fn() ought >nowadays to __count_vm_events(PGDEACTIVATE, hpage_nr_pages(page)) like >lru_deactivate_fn() does. > >(Though I think the only way shmem gets there is through drop_caches >- note the noop_backing_dev_info check in generic_fadvise(). >invalidate_mapping_pages() on shmem is rarely more than a waste of >time, since all but mapped readonly holes are undiscardably PageDirty. >Internally we added a shmem_mapping() check to stop tests wasting time >on expensive repeated drop_caches of shmem. And it's debatable whether >drop_caches updating those vm_event stats is useful or the reverse.) > >Except that a couple of lines above I see __count_vm_event(PGROTATED): >shouldn't that also use hpage_nr_pages? Then looking further through >mm/swap.c, isn't there inconsistency throughout, whether a vm_event >on a THP should be counted as 1 or hpage_nr_pages? I think originally >the idea was that manipulating a THP should count as a single event, >but now we have... a muddle. > >And what determines whether a memcg event is counted too? >mm/vmscan.c chooses to count PGDEACTIVATE and other memcg events, >mm/swap.c chooses not to count memcg events - unless it's PGLAZYFREE. > >I don't have answers. Yes, just as you did, I looked into several places where count vm event. Feel confused what we really count. Hmm... this break my mind... > >Hugh -- Wei Yang Help you, Help me