Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sun, 14 Mar 2021 18:52:28 -0600
From:   Yu Zhao <yuzhao@google.com>
To:     Zi Yan <ziy@nvidia.com>
Cc:     linux-mm@kvack.org, Alex Shi <alex.shi@linux.alibaba.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Hillf Danton <hdanton@sina.com>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Joonsoo Kim <iamjoonsoo.kim@lge.com>,
        Matthew Wilcox <willy@infradead.org>,
        Mel Gorman <mgorman@suse.de>, Michal Hocko <mhocko@suse.com>,
        Roman Gushchin <guro@fb.com>, Vlastimil Babka <vbabka@suse.cz>,
        Wei Yang <richard.weiyang@linux.alibaba.com>,
        Yang Shi <shy828301@gmail.com>,
        Ying Huang <ying.huang@intel.com>,
        linux-kernel@vger.kernel.org, page-reclaim@google.com
Subject: Re: [PATCH v1 00/14] Multigenerational LRU
Message-ID: <YE6vzPwyAApryYrf@google.com>
References: <20210313075747.3781593-1-yuzhao@google.com>
 <B2FE37C5-85B7-43AC-B6B2-43660E13FDFF@nvidia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <B2FE37C5-85B7-43AC-B6B2-43660E13FDFF@nvidia.com>
Precedence: bulk

On Sun, Mar 14, 2021 at 06:48:17PM -0400, Zi Yan wrote:
> On 13 Mar 2021, at 2:57, Yu Zhao wrote:

> > Problems
> > ========

> >   31.03%  page_vma_mapped_walk
> >   25.59%  lzo1x_1_do_compress
> >    4.63%  do_raw_spin_lock
> >    3.89%  vma_interval_tree_iter_next
> >    3.33%  vma_interval_tree_subtree_search

> > Solutions
> > =========

> >   49.36%  lzo1x_1_do_compress
> >    4.54%  page_vma_mapped_walk
> >    4.45%  memset_erms
> >    3.47%  walk_pte_range
> >    2.88%  zram_bvec_rw
> 
> Is this profile from a system with this patchset applied or not?
> Do you mind sharing some profiling data with before and after applying
> the patchset? So it would be easier to see the improvement brought by
> this patchset.

I've snipped everything else to make the context more clear.

These two kswapd profiles were collected under roughly the same memory
pressure. In other words, kswapd reclaimed (compressed) about the same
number of pages and therefore spent about the same amount of CPU time
in lzo1x_1_do_compress() in each profile.

The percentages of lzo1x_1_do_compress() are different because the
total CPU usage are different. Dividing the second percentage by the
first, we know we have roughly cut kswapd CPU usage by half.

> Are there any performance numbers for specific application (before and
> after applying the patches) you can show to demonstrate the improvement?

The kswapd profiles are from Chrome OS, i.e., laptops running the
v5.11 kernel and the Chrome browser. And we've also collected
benchmarks from various workloads on servers and phones running older
kernel versions too. Do you have a platform in mind? I'd be happy to
share the data with you. Or if you have some workloads/benchmarks, I
could collect some numbers from them too.