All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yu Zhao <yuzhao@google.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andi Kleen <ak@linux.intel.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Hillf Danton <hdanton@sina.com>, Jens Axboe <axboe@kernel.dk>,
	Jesse Barnes <jsbarnes@google.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Matthew Wilcox <willy@infradead.org>,
	Mel Gorman <mgorman@suse.de>,
	Michael Larabel <Michael@michaellarabel.com>,
	Michal Hocko <mhocko@kernel.org>, Rik van Riel <riel@surriel.com>,
	Vlastimil Babka <vbabka@suse.cz>, Will Deacon <will@kernel.org>,
	Ying Huang <ying.huang@intel.com>,
	linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	page-reclaim@google.com, x86@kernel.org,
	Konstantin Kharlamov <Hi-Angel@yandex.ru>
Subject: Re: [PATCH v6 4/9] mm: multigenerational lru: groundwork
Date: Tue, 11 Jan 2022 19:16:15 -0700	[thread overview]
Message-ID: <Yd457900iUIzwpnc@google.com> (raw)
In-Reply-To: <878rvm661z.fsf@linux.ibm.com>

On Tue, Jan 11, 2022 at 01:46:24PM +0530, Aneesh Kumar K.V wrote:
> Yu Zhao <yuzhao@google.com> writes:
> 
> .....
> 
>  +
> > +/*
> > + * Evictable pages are divided into multiple generations. The youngest and the
> > + * oldest generation numbers, max_seq and min_seq, are monotonically increasing.
> > + * They form a sliding window of a variable size [MIN_NR_GENS, MAX_NR_GENS]. An
> > + * offset within MAX_NR_GENS, gen, indexes the lru list of the corresponding
> > + * generation. The gen counter in folio->flags stores gen+1 while a page is on
> > + * lrugen->lists[]. Otherwise, it stores 0.
> > + *
> > + * A page is added to the youngest generation on faulting. The aging needs to
> > + * check the accessed bit at least twice before handing this page over to the
> > + * eviction. The first check takes care of the accessed bit set on the initial
> > + * fault; the second check makes sure this page hasn't been used since then.
> > + * This process, AKA second chance, requires a minimum of two generations,
> > + * hence MIN_NR_GENS. And to be compatible with the active/inactive lru, these
> > + * two generations are mapped to the active; the rest of generations, if they
> > + * exist, are mapped to the inactive. PG_active is always cleared while a page
> > + * is on lrugen->lists[] so that demotion, which happens consequently when the
> > + * aging creates a new generation, needs not to worry about it.
> > + */
> 
> Where do we clear PG_active in the code? Is this the reason we endup
> with

We clear PG_active when we add a page (folio) to MGLRU lists:
  include/linux/mm_inline.h
    lru_gen_add_folio()
	do {
		new_flags = old_flags = READ_ONCE(folio->flags);

		...

		new_flags &= ~(LRU_GEN_MASK | BIT(PG_active));
                                                  ^^^^^^^^^
		...

	} while (cmpxchg(&folio->flags, old_flags, new_flags) != old_flags);

We also set it when we isolate a page (for page migration):
  include/linux/mm_inline.h
    lru_gen_del_folio()
	do {
		new_flags = old_flags = READ_ONCE(folio->flags);

		...

		else if (lru_gen_is_active(lruvec, gen))
			new_flags |= BIT(PG_active);
                                         ^^^^^^^^^
	} while (cmpxchg(&folio->flags, old_flags, new_flags) != old_flags);

> 
>   void deactivate_page(struct page *page)
>   {
>  -	if (PageLRU(page) && PageActive(page) && !PageUnevictable(page)) {
>  +	if (PageLRU(page) && !PageUnevictable(page) && (PageActive(page) || lru_gen_enabled())) {

That's correct.

> > +#define MIN_NR_GENS		2U
> > +#define MAX_NR_GENS		((unsigned int)CONFIG_NR_LRU_GENS)
> > +
> > +struct lru_gen_struct {
> > +	/* the aging increments the youngest generation number */
> > +	unsigned long max_seq;
> > +	/* the eviction increments the oldest generation numbers */
> > +	unsigned long min_seq[ANON_AND_FILE];
> > +	/* the birth time of each generation in jiffies */
> > +	unsigned long timestamps[MAX_NR_GENS];
> > +	/* the multigenerational lru lists */
> > +	struct list_head lists[MAX_NR_GENS][ANON_AND_FILE][MAX_NR_ZONES];
> > +	/* the sizes of the above lists */
> > +	unsigned long nr_pages[MAX_NR_GENS][ANON_AND_FILE][MAX_NR_ZONES];
> > +	/* whether the multigenerational lru is enabled */
> > +	bool enabled;
> > +};
> > +
> 
> ....
> 
> >  static void __meminit zone_init_internals(struct zone *zone, enum zone_type idx, int nid,
> > diff --git a/mm/swap.c b/mm/swap.c
> > index e8c9dc6d0377..d7dde3b7d4b5 100644
> > --- a/mm/swap.c
> > +++ b/mm/swap.c
> > @@ -462,6 +462,11 @@ void folio_add_lru(struct folio *folio)
> >  	VM_BUG_ON_FOLIO(folio_test_active(folio) && folio_test_unevictable(folio), folio);
> >  	VM_BUG_ON_FOLIO(folio_test_lru(folio), folio);
> >  
> > +	/* see the comment in lru_gen_add_folio() */
> > +	if (lru_gen_enabled() && !folio_test_unevictable(folio) &&
> > +	    task_in_lru_fault() && !(current->flags & PF_MEMALLOC))
> > +		folio_set_active(folio);
> > +
> 
> 
> Can you explain this better? What is the significance of marking the
> folio active here. Do we need to differentiate parallel page faults (across
> different vmas) w.r.t task_in_lru_fault()?

All pages faulted in need to be added to the youngest generation. But
without PG_active, lru_gen_add_folio() doesn't know whether a page was
faulted in, or something else, e.g., page cache readahead. This is
because pages aren't immediately sent to lru_gen_add_folio(). They are
batched by lru_pvecs:

/**
 * folio_add_lru - Add a folio to an LRU list.
 * @folio: The folio to be added to the LRU.
 *
 * Queue the folio for addition to the LRU. The decision on whether
 * to add the page to the [in]active [file|anon] list is deferred until the
 * pagevec is drained. This gives a chance for the caller of folio_add_lru()
 * have the folio added to the active list using folio_mark_accessed().
 */
void folio_add_lru(struct folio *folio)
{
	struct pagevec *pvec;

	VM_BUG_ON_FOLIO(folio_test_active(folio) && folio_test_unevictable(folio), folio);
	VM_BUG_ON_FOLIO(folio_test_lru(folio), folio);

	/* see the comment in lru_gen_add_folio() */
	if (lru_gen_enabled() && !folio_test_unevictable(folio) &&
	    lru_gen_in_pgfault() && !(current->flags & PF_MEMALLOC))
		folio_set_active(folio);

	folio_get(folio);
	local_lock(&lru_pvecs.lock);
	pvec = this_cpu_ptr(&lru_pvecs.lru_add);
	if (pagevec_add_and_need_flush(pvec, &folio->page))
		__pagevec_lru_add(pvec);
	local_unlock(&lru_pvecs.lock);
}

WARNING: multiple messages have this Message-ID (diff)
From: Yu Zhao <yuzhao@google.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andi Kleen <ak@linux.intel.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Hillf Danton <hdanton@sina.com>, Jens Axboe <axboe@kernel.dk>,
	Jesse Barnes <jsbarnes@google.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Matthew Wilcox <willy@infradead.org>,
	Mel Gorman <mgorman@suse.de>,
	Michael Larabel <Michael@michaellarabel.com>,
	Michal Hocko <mhocko@kernel.org>, Rik van Riel <riel@surriel.com>,
	Vlastimil Babka <vbabka@suse.cz>, Will Deacon <will@kernel.org>,
	Ying Huang <ying.huang@intel.com>,
	linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	page-reclaim@google.com, x86@kernel.org,
	Konstantin Kharlamov <Hi-Angel@yandex.ru>
Subject: Re: [PATCH v6 4/9] mm: multigenerational lru: groundwork
Date: Tue, 11 Jan 2022 19:16:15 -0700	[thread overview]
Message-ID: <Yd457900iUIzwpnc@google.com> (raw)
In-Reply-To: <878rvm661z.fsf@linux.ibm.com>

On Tue, Jan 11, 2022 at 01:46:24PM +0530, Aneesh Kumar K.V wrote:
> Yu Zhao <yuzhao@google.com> writes:
> 
> .....
> 
>  +
> > +/*
> > + * Evictable pages are divided into multiple generations. The youngest and the
> > + * oldest generation numbers, max_seq and min_seq, are monotonically increasing.
> > + * They form a sliding window of a variable size [MIN_NR_GENS, MAX_NR_GENS]. An
> > + * offset within MAX_NR_GENS, gen, indexes the lru list of the corresponding
> > + * generation. The gen counter in folio->flags stores gen+1 while a page is on
> > + * lrugen->lists[]. Otherwise, it stores 0.
> > + *
> > + * A page is added to the youngest generation on faulting. The aging needs to
> > + * check the accessed bit at least twice before handing this page over to the
> > + * eviction. The first check takes care of the accessed bit set on the initial
> > + * fault; the second check makes sure this page hasn't been used since then.
> > + * This process, AKA second chance, requires a minimum of two generations,
> > + * hence MIN_NR_GENS. And to be compatible with the active/inactive lru, these
> > + * two generations are mapped to the active; the rest of generations, if they
> > + * exist, are mapped to the inactive. PG_active is always cleared while a page
> > + * is on lrugen->lists[] so that demotion, which happens consequently when the
> > + * aging creates a new generation, needs not to worry about it.
> > + */
> 
> Where do we clear PG_active in the code? Is this the reason we endup
> with

We clear PG_active when we add a page (folio) to MGLRU lists:
  include/linux/mm_inline.h
    lru_gen_add_folio()
	do {
		new_flags = old_flags = READ_ONCE(folio->flags);

		...

		new_flags &= ~(LRU_GEN_MASK | BIT(PG_active));
                                                  ^^^^^^^^^
		...

	} while (cmpxchg(&folio->flags, old_flags, new_flags) != old_flags);

We also set it when we isolate a page (for page migration):
  include/linux/mm_inline.h
    lru_gen_del_folio()
	do {
		new_flags = old_flags = READ_ONCE(folio->flags);

		...

		else if (lru_gen_is_active(lruvec, gen))
			new_flags |= BIT(PG_active);
                                         ^^^^^^^^^
	} while (cmpxchg(&folio->flags, old_flags, new_flags) != old_flags);

> 
>   void deactivate_page(struct page *page)
>   {
>  -	if (PageLRU(page) && PageActive(page) && !PageUnevictable(page)) {
>  +	if (PageLRU(page) && !PageUnevictable(page) && (PageActive(page) || lru_gen_enabled())) {

That's correct.

> > +#define MIN_NR_GENS		2U
> > +#define MAX_NR_GENS		((unsigned int)CONFIG_NR_LRU_GENS)
> > +
> > +struct lru_gen_struct {
> > +	/* the aging increments the youngest generation number */
> > +	unsigned long max_seq;
> > +	/* the eviction increments the oldest generation numbers */
> > +	unsigned long min_seq[ANON_AND_FILE];
> > +	/* the birth time of each generation in jiffies */
> > +	unsigned long timestamps[MAX_NR_GENS];
> > +	/* the multigenerational lru lists */
> > +	struct list_head lists[MAX_NR_GENS][ANON_AND_FILE][MAX_NR_ZONES];
> > +	/* the sizes of the above lists */
> > +	unsigned long nr_pages[MAX_NR_GENS][ANON_AND_FILE][MAX_NR_ZONES];
> > +	/* whether the multigenerational lru is enabled */
> > +	bool enabled;
> > +};
> > +
> 
> ....
> 
> >  static void __meminit zone_init_internals(struct zone *zone, enum zone_type idx, int nid,
> > diff --git a/mm/swap.c b/mm/swap.c
> > index e8c9dc6d0377..d7dde3b7d4b5 100644
> > --- a/mm/swap.c
> > +++ b/mm/swap.c
> > @@ -462,6 +462,11 @@ void folio_add_lru(struct folio *folio)
> >  	VM_BUG_ON_FOLIO(folio_test_active(folio) && folio_test_unevictable(folio), folio);
> >  	VM_BUG_ON_FOLIO(folio_test_lru(folio), folio);
> >  
> > +	/* see the comment in lru_gen_add_folio() */
> > +	if (lru_gen_enabled() && !folio_test_unevictable(folio) &&
> > +	    task_in_lru_fault() && !(current->flags & PF_MEMALLOC))
> > +		folio_set_active(folio);
> > +
> 
> 
> Can you explain this better? What is the significance of marking the
> folio active here. Do we need to differentiate parallel page faults (across
> different vmas) w.r.t task_in_lru_fault()?

All pages faulted in need to be added to the youngest generation. But
without PG_active, lru_gen_add_folio() doesn't know whether a page was
faulted in, or something else, e.g., page cache readahead. This is
because pages aren't immediately sent to lru_gen_add_folio(). They are
batched by lru_pvecs:

/**
 * folio_add_lru - Add a folio to an LRU list.
 * @folio: The folio to be added to the LRU.
 *
 * Queue the folio for addition to the LRU. The decision on whether
 * to add the page to the [in]active [file|anon] list is deferred until the
 * pagevec is drained. This gives a chance for the caller of folio_add_lru()
 * have the folio added to the active list using folio_mark_accessed().
 */
void folio_add_lru(struct folio *folio)
{
	struct pagevec *pvec;

	VM_BUG_ON_FOLIO(folio_test_active(folio) && folio_test_unevictable(folio), folio);
	VM_BUG_ON_FOLIO(folio_test_lru(folio), folio);

	/* see the comment in lru_gen_add_folio() */
	if (lru_gen_enabled() && !folio_test_unevictable(folio) &&
	    lru_gen_in_pgfault() && !(current->flags & PF_MEMALLOC))
		folio_set_active(folio);

	folio_get(folio);
	local_lock(&lru_pvecs.lock);
	pvec = this_cpu_ptr(&lru_pvecs.lru_add);
	if (pagevec_add_and_need_flush(pvec, &folio->page))
		__pagevec_lru_add(pvec);
	local_unlock(&lru_pvecs.lock);
}

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-01-12  2:16 UTC|newest]

Thread overview: 223+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-04 20:22 [PATCH v6 0/9] Multigenerational LRU Framework Yu Zhao
2022-01-04 20:22 ` Yu Zhao
2022-01-04 20:22 ` [PATCH v6 1/9] mm: x86, arm64: add arch_has_hw_pte_young() Yu Zhao
2022-01-04 20:22   ` Yu Zhao
2022-01-05 10:45   ` Will Deacon
2022-01-05 10:45     ` Will Deacon
2022-01-05 20:47     ` Yu Zhao
2022-01-05 20:47       ` Yu Zhao
2022-01-06 10:30       ` Will Deacon
2022-01-06 10:30         ` Will Deacon
2022-01-07  7:25         ` Yu Zhao
2022-01-07  7:25           ` Yu Zhao
2022-01-11 14:19           ` Will Deacon
2022-01-11 14:19             ` Will Deacon
2022-01-11 22:27             ` Yu Zhao
2022-01-11 22:27               ` Yu Zhao
2022-01-04 20:22 ` [PATCH v6 2/9] mm: x86: add CONFIG_ARCH_HAS_NONLEAF_PMD_YOUNG Yu Zhao
2022-01-04 20:22   ` Yu Zhao
2022-01-04 21:24   ` Linus Torvalds
2022-01-04 21:24     ` Linus Torvalds
2022-01-04 20:22 ` [PATCH v6 3/9] mm/vmscan.c: refactor shrink_node() Yu Zhao
2022-01-04 20:22   ` Yu Zhao
2022-01-04 20:22 ` [PATCH v6 4/9] mm: multigenerational lru: groundwork Yu Zhao
2022-01-04 20:22   ` Yu Zhao
2022-01-04 21:34   ` Linus Torvalds
2022-01-04 21:34     ` Linus Torvalds
2022-01-11  8:16   ` Aneesh Kumar K.V
2022-01-11  8:16     ` Aneesh Kumar K.V
2022-01-12  2:16     ` Yu Zhao [this message]
2022-01-12  2:16       ` Yu Zhao
2022-01-04 20:22 ` [PATCH v6 5/9] mm: multigenerational lru: mm_struct list Yu Zhao
2022-01-04 20:22   ` Yu Zhao
2022-01-07  9:06   ` Michal Hocko
2022-01-07  9:06     ` Michal Hocko
2022-01-08  0:19     ` Yu Zhao
2022-01-08  0:19       ` Yu Zhao
2022-01-10 15:21       ` Michal Hocko
2022-01-10 15:21         ` Michal Hocko
2022-01-12  8:08         ` Yu Zhao
2022-01-12  8:08           ` Yu Zhao
2022-01-04 20:22 ` [PATCH v6 6/9] mm: multigenerational lru: aging Yu Zhao
2022-01-04 20:22   ` Yu Zhao
2022-01-06 16:06   ` Michal Hocko
2022-01-06 16:06     ` Michal Hocko
2022-01-06 21:27     ` Yu Zhao
2022-01-06 21:27       ` Yu Zhao
2022-01-07  8:43       ` Michal Hocko
2022-01-07  8:43         ` Michal Hocko
2022-01-07 21:12         ` Yu Zhao
2022-01-07 21:12           ` Yu Zhao
2022-01-06 16:12   ` Michal Hocko
2022-01-06 16:12     ` Michal Hocko
2022-01-06 21:41     ` Yu Zhao
2022-01-06 21:41       ` Yu Zhao
2022-01-07  8:55       ` Michal Hocko
2022-01-07  8:55         ` Michal Hocko
2022-01-07  9:00         ` Michal Hocko
2022-01-07  9:00           ` Michal Hocko
2022-01-10  3:58           ` Yu Zhao
2022-01-10  3:58             ` Yu Zhao
2022-01-10 14:37             ` Michal Hocko
2022-01-10 14:37               ` Michal Hocko
2022-01-13  9:43               ` Yu Zhao
2022-01-13  9:43                 ` Yu Zhao
2022-01-13 12:02                 ` Michal Hocko
2022-01-13 12:02                   ` Michal Hocko
2022-01-19  6:31                   ` Yu Zhao
2022-01-19  6:31                     ` Yu Zhao
2022-01-19  9:44                     ` Michal Hocko
2022-01-19  9:44                       ` Michal Hocko
2022-01-10 15:01     ` Michal Hocko
2022-01-10 15:01       ` Michal Hocko
2022-01-10 16:01       ` Vlastimil Babka
2022-01-10 16:01         ` Vlastimil Babka
2022-01-10 16:25         ` Michal Hocko
2022-01-10 16:25           ` Michal Hocko
2022-01-11 23:16       ` Yu Zhao
2022-01-11 23:16         ` Yu Zhao
2022-01-12 10:28         ` Michal Hocko
2022-01-12 10:28           ` Michal Hocko
2022-01-13  9:25           ` Yu Zhao
2022-01-13  9:25             ` Yu Zhao
2022-01-07 13:11   ` Michal Hocko
2022-01-07 13:11     ` Michal Hocko
2022-01-07 23:36     ` Yu Zhao
2022-01-07 23:36       ` Yu Zhao
2022-01-10 15:35       ` Michal Hocko
2022-01-10 15:35         ` Michal Hocko
2022-01-11  1:18         ` Yu Zhao
2022-01-11  1:18           ` Yu Zhao
2022-01-11  9:00           ` Michal Hocko
2022-01-11  9:00             ` Michal Hocko
     [not found]         ` <1641900108.61dd684cb0e59@mail.inbox.lv>
2022-01-11 12:15           ` Michal Hocko
2022-01-11 12:15             ` Michal Hocko
2022-01-13 17:00             ` Alexey Avramov
2022-01-13 17:00               ` Alexey Avramov
2022-01-11 14:22         ` Alexey Avramov
2022-01-11 14:22           ` Alexey Avramov
2022-01-07 14:44   ` Michal Hocko
2022-01-07 14:44     ` Michal Hocko
2022-01-10  4:47     ` Yu Zhao
2022-01-10  4:47       ` Yu Zhao
2022-01-10 10:54       ` Michal Hocko
2022-01-10 10:54         ` Michal Hocko
2022-01-19  7:04         ` Yu Zhao
2022-01-19  7:04           ` Yu Zhao
2022-01-19  9:42           ` Michal Hocko
2022-01-19  9:42             ` Michal Hocko
2022-01-23 21:28             ` Yu Zhao
2022-01-23 21:28               ` Yu Zhao
2022-01-24 14:01               ` Michal Hocko
2022-01-24 14:01                 ` Michal Hocko
2022-01-10 16:57   ` Michal Hocko
2022-01-10 16:57     ` Michal Hocko
2022-01-12  1:01     ` Yu Zhao
2022-01-12  1:01       ` Yu Zhao
2022-01-12 10:17       ` Michal Hocko
2022-01-12 10:17         ` Michal Hocko
2022-01-12 23:43         ` Yu Zhao
2022-01-12 23:43           ` Yu Zhao
2022-01-13 11:57           ` Michal Hocko
2022-01-13 11:57             ` Michal Hocko
2022-01-23 21:40             ` Yu Zhao
2022-01-23 21:40               ` Yu Zhao
2022-01-04 20:22 ` [PATCH v6 7/9] mm: multigenerational lru: eviction Yu Zhao
2022-01-04 20:22   ` Yu Zhao
2022-01-11 10:37   ` Aneesh Kumar K.V
2022-01-11 10:37     ` Aneesh Kumar K.V
2022-01-12  8:05     ` Yu Zhao
2022-01-12  8:05       ` Yu Zhao
2022-01-04 20:22 ` [PATCH v6 8/9] mm: multigenerational lru: user interface Yu Zhao
2022-01-04 20:22   ` Yu Zhao
2022-01-10 10:27   ` Mike Rapoport
2022-01-10 10:27     ` Mike Rapoport
2022-01-12  8:35     ` Yu Zhao
2022-01-12  8:35       ` Yu Zhao
2022-01-12 10:31       ` Michal Hocko
2022-01-12 10:31         ` Michal Hocko
2022-01-12 15:45       ` Mike Rapoport
2022-01-12 15:45         ` Mike Rapoport
2022-01-13  9:47         ` Yu Zhao
2022-01-13  9:47           ` Yu Zhao
2022-01-13 10:31   ` Aneesh Kumar K.V
2022-01-13 10:31     ` Aneesh Kumar K.V
2022-01-13 23:02     ` Yu Zhao
2022-01-13 23:02       ` Yu Zhao
2022-01-14  5:20       ` Aneesh Kumar K.V
2022-01-14  5:20         ` Aneesh Kumar K.V
2022-01-14  6:50         ` Yu Zhao
2022-01-14  6:50           ` Yu Zhao
2022-01-04 20:22 ` [PATCH v6 9/9] mm: multigenerational lru: Kconfig Yu Zhao
2022-01-04 20:22   ` Yu Zhao
2022-01-04 21:39   ` Linus Torvalds
2022-01-04 21:39     ` Linus Torvalds
2022-01-04 20:22 ` [PATCH v6 0/9] Multigenerational LRU Framework Yu Zhao
2022-01-04 20:30 ` Yu Zhao
2022-01-04 20:30   ` Yu Zhao
2022-01-04 21:43   ` Linus Torvalds
2022-01-04 21:43     ` Linus Torvalds
2022-01-05 21:12     ` Yu Zhao
2022-01-05 21:12       ` Yu Zhao
2022-01-07  9:38   ` Michal Hocko
2022-01-07  9:38     ` Michal Hocko
2022-01-07 18:45     ` Yu Zhao
2022-01-07 18:45       ` Yu Zhao
2022-01-10 15:39       ` Michal Hocko
2022-01-10 15:39         ` Michal Hocko
2022-01-10 22:04         ` Yu Zhao
2022-01-10 22:04           ` Yu Zhao
2022-01-10 22:46           ` Jesse Barnes
2022-01-10 22:46             ` Jesse Barnes
2022-01-11  1:41             ` Linus Torvalds
2022-01-11  1:41               ` Linus Torvalds
2022-01-11 10:40             ` Michal Hocko
2022-01-11 10:40               ` Michal Hocko
2022-01-11  8:41   ` Yu Zhao
2022-01-11  8:41     ` Yu Zhao
2022-01-11  8:53     ` Holger Hoffstätte
2022-01-11  8:53       ` Holger Hoffstätte
2022-01-11  9:26     ` Jan Alexander Steffens (heftig)
2022-01-11 16:04     ` Shuang Zhai
2022-01-11 16:04       ` Shuang Zhai
2022-01-12  1:46     ` Suleiman Souhlal
2022-01-12  1:46       ` Suleiman Souhlal
2022-01-12  6:07     ` Sofia Trinh
2022-01-12  6:07       ` Sofia Trinh
2022-01-12 16:17       ` Daniel Byrne
2022-01-18  9:21     ` Yu Zhao
2022-01-18  9:21       ` Yu Zhao
2022-01-18  9:36     ` Donald Carr
2022-01-18  9:36       ` Donald Carr
2022-01-19 20:19     ` Steven Barrett
2022-01-19 20:19       ` Steven Barrett
2022-01-19 22:25     ` Brian Geffon
2022-01-19 22:25       ` Brian Geffon
2022-01-05  2:44 ` Shuang Zhai
2022-01-05  2:44   ` Shuang Zhai
2022-01-05  8:55 ` SeongJae Park
2022-01-05  8:55   ` SeongJae Park
2022-01-05 10:53   ` Yu Zhao
2022-01-05 10:53     ` Yu Zhao
2022-01-05 11:12     ` Borislav Petkov
2022-01-05 11:12       ` Borislav Petkov
2022-01-05 11:25     ` SeongJae Park
2022-01-05 11:25       ` SeongJae Park
2022-01-05 21:06       ` Yu Zhao
2022-01-05 21:06         ` Yu Zhao
2022-01-10 14:49 ` Alexey Avramov
2022-01-10 14:49   ` Alexey Avramov
2022-01-11 10:24 ` Alexey Avramov
2022-01-11 10:24   ` Alexey Avramov
2022-01-12 20:56 ` Oleksandr Natalenko
2022-01-12 20:56   ` Oleksandr Natalenko
2022-01-13  8:59   ` Yu Zhao
2022-01-13  8:59     ` Yu Zhao
2022-01-23  5:43 ` Barry Song
2022-01-23  5:43   ` Barry Song
2022-01-25  6:48   ` Yu Zhao
2022-01-25  6:48     ` Yu Zhao
2022-01-28  8:54     ` Barry Song
2022-01-28  8:54       ` Barry Song
2022-02-08  9:16       ` Yu Zhao
2022-02-08  9:16         ` Yu Zhao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yd457900iUIzwpnc@google.com \
    --to=yuzhao@google.com \
    --cc=Hi-Angel@yandex.ru \
    --cc=Michael@michaellarabel.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=axboe@kernel.dk \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=hannes@cmpxchg.org \
    --cc=hdanton@sina.com \
    --cc=jsbarnes@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@kernel.org \
    --cc=page-reclaim@google.com \
    --cc=riel@surriel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@suse.cz \
    --cc=will@kernel.org \
    --cc=willy@infradead.org \
    --cc=x86@kernel.org \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.