All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Barry Song <21cnbao@gmail.com>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
	"Will Deacon" <will@kernel.org>, Linux-MM <linux-mm@kvack.org>,
	LAK <linux-arm-kernel@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	hanchuanhua <hanchuanhua@oppo.com>,
	"张诗明(Simon Zhang)" <zhangshiming@oppo.com>, 郭健 <guojian@oppo.com>,
	"Barry Song" <v-songbaohua@oppo.com>,
	"Huang, Ying" <ying.huang@intel.com>,
	"Minchan Kim" <minchan@kernel.org>,
	"Johannes Weiner" <hannes@cmpxchg.org>,
	"Hugh Dickins" <hughd@google.com>, "Shaohua Li" <shli@kernel.org>,
	"Rik van Riel" <riel@redhat.com>,
	"Andrea Arcangeli" <aarcange@redhat.com>,
	"Steven Price" <steven.price@arm.com>
Subject: Re: [PATCH] arm64: enable THP_SWAP for arm64
Date: Wed, 25 May 2022 17:54:39 +0100	[thread overview]
Message-ID: <Yo5fTzEUFW6lbwnI@arm.com> (raw)
In-Reply-To: <CAGsJ_4wSmZo9+Anzq_WjF=xACRT7p0EJ86de6C=8xhGpTBOHQg@mail.gmail.com>

On Wed, May 25, 2022 at 11:10:41PM +1200, Barry Song wrote:
> On Wed, May 25, 2022 at 7:14 AM Catalin Marinas <catalin.marinas@arm.com> wrote:
> > I think this should work and with your other proposal it would be
> > limited to MTE pages:
> >
> > #define arch_thp_swp_supported(page)    (!test_bit(PG_mte_tagged, &page->flags))
> >
> > Are THP pages loaded from swap as a whole or are they split? IIRC the
> 
> i can confirm thp is written as a whole through:
> [   90.622863]  __swap_writepage+0xe8/0x580
> [   90.622881]  swap_writepage+0x44/0xf8
> [   90.622891]  pageout+0xe0/0x2a8
> [   90.622906]  shrink_page_list+0x9dc/0xde0
> [   90.622917]  shrink_inactive_list+0x1ec/0x3c8
> [   90.622928]  shrink_lruvec+0x3dc/0x628
> [   90.622939]  shrink_node+0x37c/0x6a0
> [   90.622950]  balance_pgdat+0x354/0x668
> [   90.622961]  kswapd+0x1e0/0x3c0
> [   90.622972]  kthread+0x110/0x120
> 
> but i have never got a backtrace in which thp is loaded as a whole though it
> seems the code has this path:
> int swap_readpage(struct page *page, bool synchronous)
> {
>         ...
>         bio = bio_alloc(sis->bdev, 1, REQ_OP_READ, GFP_KERNEL);
>         bio->bi_iter.bi_sector = swap_page_sector(page);
>         bio->bi_end_io = end_swap_bio_read;
>         bio_add_page(bio, page, thp_size(page), 0);
>         ...
>         submit_bio(bio);
> }
> 
> > splitting still happens but after the swapping out finishes. Even if
> > they are loaded as 4K pages, we still have the mte_save_tags() that only
> > understands small pages currently, so rejecting THP pages is probably
> > best.
> 
> as anyway i don't have a mte-hardware to do a valid test to go any
> further, so i will totally disable thp_swp for hardware having mte for
> this moment in patch v2.

It makes sense. If we decide to improve this for MTE, we'll change the
arch check.

Thanks.

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Barry Song <21cnbao@gmail.com>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
	"Will Deacon" <will@kernel.org>, Linux-MM <linux-mm@kvack.org>,
	LAK <linux-arm-kernel@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	hanchuanhua <hanchuanhua@oppo.com>,
	"张诗明(Simon Zhang)" <zhangshiming@oppo.com>, 郭健 <guojian@oppo.com>,
	"Barry Song" <v-songbaohua@oppo.com>,
	"Huang, Ying" <ying.huang@intel.com>,
	"Minchan Kim" <minchan@kernel.org>,
	"Johannes Weiner" <hannes@cmpxchg.org>,
	"Hugh Dickins" <hughd@google.com>, "Shaohua Li" <shli@kernel.org>,
	"Rik van Riel" <riel@redhat.com>,
	"Andrea Arcangeli" <aarcange@redhat.com>,
	"Steven Price" <steven.price@arm.com>
Subject: Re: [PATCH] arm64: enable THP_SWAP for arm64
Date: Wed, 25 May 2022 17:54:39 +0100	[thread overview]
Message-ID: <Yo5fTzEUFW6lbwnI@arm.com> (raw)
In-Reply-To: <CAGsJ_4wSmZo9+Anzq_WjF=xACRT7p0EJ86de6C=8xhGpTBOHQg@mail.gmail.com>

On Wed, May 25, 2022 at 11:10:41PM +1200, Barry Song wrote:
> On Wed, May 25, 2022 at 7:14 AM Catalin Marinas <catalin.marinas@arm.com> wrote:
> > I think this should work and with your other proposal it would be
> > limited to MTE pages:
> >
> > #define arch_thp_swp_supported(page)    (!test_bit(PG_mte_tagged, &page->flags))
> >
> > Are THP pages loaded from swap as a whole or are they split? IIRC the
> 
> i can confirm thp is written as a whole through:
> [   90.622863]  __swap_writepage+0xe8/0x580
> [   90.622881]  swap_writepage+0x44/0xf8
> [   90.622891]  pageout+0xe0/0x2a8
> [   90.622906]  shrink_page_list+0x9dc/0xde0
> [   90.622917]  shrink_inactive_list+0x1ec/0x3c8
> [   90.622928]  shrink_lruvec+0x3dc/0x628
> [   90.622939]  shrink_node+0x37c/0x6a0
> [   90.622950]  balance_pgdat+0x354/0x668
> [   90.622961]  kswapd+0x1e0/0x3c0
> [   90.622972]  kthread+0x110/0x120
> 
> but i have never got a backtrace in which thp is loaded as a whole though it
> seems the code has this path:
> int swap_readpage(struct page *page, bool synchronous)
> {
>         ...
>         bio = bio_alloc(sis->bdev, 1, REQ_OP_READ, GFP_KERNEL);
>         bio->bi_iter.bi_sector = swap_page_sector(page);
>         bio->bi_end_io = end_swap_bio_read;
>         bio_add_page(bio, page, thp_size(page), 0);
>         ...
>         submit_bio(bio);
> }
> 
> > splitting still happens but after the swapping out finishes. Even if
> > they are loaded as 4K pages, we still have the mte_save_tags() that only
> > understands small pages currently, so rejecting THP pages is probably
> > best.
> 
> as anyway i don't have a mte-hardware to do a valid test to go any
> further, so i will totally disable thp_swp for hardware having mte for
> this moment in patch v2.

It makes sense. If we decide to improve this for MTE, we'll change the
arch check.

Thanks.

-- 
Catalin

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

  reply	other threads:[~2022-05-25 16:54 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-24  7:14 [PATCH] arm64: enable THP_SWAP for arm64 Barry Song
2022-05-24  7:14 ` Barry Song
2022-05-24  8:12 ` Catalin Marinas
2022-05-24  8:12   ` Catalin Marinas
2022-05-24 10:05   ` Barry Song
2022-05-24 10:05     ` Barry Song
2022-05-24 11:15     ` Barry Song
2022-05-24 11:15       ` Barry Song
2022-05-26  8:13       ` Anshuman Khandual
2022-05-26  8:13         ` Anshuman Khandual
2022-05-24 19:14     ` Catalin Marinas
2022-05-24 19:14       ` Catalin Marinas
2022-05-25 11:10       ` Barry Song
2022-05-25 11:10         ` Barry Song
2022-05-25 16:54         ` Catalin Marinas [this message]
2022-05-25 16:54           ` Catalin Marinas
2022-05-25 17:49         ` Yang Shi
2022-05-25 17:49           ` Yang Shi
2022-05-26  9:19           ` Barry Song
2022-05-26  9:19             ` Barry Song
2022-05-26 17:02             ` Yang Shi
2022-05-26 17:02               ` Yang Shi
2022-05-27  7:29               ` Barry Song
2022-05-27  7:29                 ` Barry Song

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=Yo5fTzEUFW6lbwnI@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=21cnbao@gmail.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=guojian@oppo.com \
    --cc=hanchuanhua@oppo.com \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=riel@redhat.com \
    --cc=shli@kernel.org \
    --cc=steven.price@arm.com \
    --cc=v-songbaohua@oppo.com \
    --cc=will@kernel.org \
    --cc=ying.huang@intel.com \
    --cc=zhangshiming@oppo.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.