linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Ning Zhang <ningzhang@linux.alibaba.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Michal Hocko <mhocko@kernel.org>,
	Vladimir Davydov <vdavydov.dev@gmail.com>,
	Yu Zhao <yuzhao@google.com>
Subject: Re: [RFC 1/6] mm, thp: introduce thp zero subpages reclaim
Date: Thu, 28 Oct 2021 13:53:30 +0100	[thread overview]
Message-ID: <YXqdSgV9XmgOv3tp@casper.infradead.org> (raw)
In-Reply-To: <1635422215-99394-2-git-send-email-ningzhang@linux.alibaba.com>

On Thu, Oct 28, 2021 at 07:56:50PM +0800, Ning Zhang wrote:
> +++ b/include/linux/huge_mm.h
> @@ -185,6 +185,15 @@ unsigned long thp_get_unmapped_area(struct file *filp, unsigned long addr,
>  void free_transhuge_page(struct page *page);
>  bool is_transparent_hugepage(struct page *page);
>  
> +#ifdef CONFIG_MEMCG
> +int zsr_get_hpage(struct hpage_reclaim *hr_queue, struct page **reclaim_page);
> +unsigned long zsr_reclaim_hpage(struct lruvec *lruvec, struct page *page);
> +static inline struct list_head *hpage_reclaim_list(struct page *page)
> +{
> +	return &page[3].hpage_reclaim_list;
> +}
> +#endif

I don't think any of this needs to be under an ifdef.  That goes for a
lot of your other additions to header files.

> @@ -1110,6 +1121,10 @@ unsigned long mem_cgroup_soft_limit_reclaim(pg_data_t *pgdat, int order,
>  						gfp_t gfp_mask,
>  						unsigned long *total_scanned);
>  
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +void del_hpage_from_queue(struct page *page);
> +#endif

That name is too generic.  Also, to avoid ifdefs in code, it should be:

#ifdef CONFIG_TRANSPARENT_HUGEPAGE
void del_hpage_from_queue(struct page *page);
#else
static inline void del_hpage_from_queue(struct page *page) { }
#endif

> @@ -159,6 +159,12 @@ struct page {
>  			/* For both global and memcg */
>  			struct list_head deferred_list;
>  		};
> +		struct {	 /* Third tail page of compound page */
> +			unsigned long _compound_pad_2;
> +			unsigned long _compound_pad_3;
> +			/* For zero subpages reclaim */
> +			struct list_head hpage_reclaim_list;

Why do you need _compound_pad_3 here?

> +++ b/include/linux/mmzone.h
> @@ -787,6 +787,12 @@ struct deferred_split {
>  	struct list_head split_queue;
>  	unsigned long split_queue_len;
>  };
> +
> +struct hpage_reclaim {
> +	spinlock_t reclaim_queue_lock;
> +	struct list_head reclaim_queue;
> +	unsigned long reclaim_queue_len;
> +};

Have you considered using an XArray instead of a linked list?

> +static bool hpage_estimate_zero(struct page *page)
> +{
> +	unsigned int i, maybe_zero_pages = 0, offset = 0;
> +	void *addr;
> +
> +#define BYTES_PER_LONG (BITS_PER_LONG / BITS_PER_BYTE)

BYTES_PER_LONG is simply sizeof(long).
Also, I'd check the entire cacheline rather than just one word; it's
essentially free.

> +#ifdef CONFIG_MMU
> +#define ZSR_PG_MLOCK(flag)	(1UL << flag)
> +#else
> +#define ZSR_PG_MLOCK(flag)	0
> +#endif

Or use __PG_MLOCKED ?

> +#ifdef CONFIG_ARCH_USES_PG_UNCACHED
> +#define ZSR_PG_UNCACHED(flag)	(1UL << flag)
> +#else
> +#define ZSR_PG_UNCACHED(flag)	0
> +#endif

Define __PG_UNCACHED in page-flags.h?

> +#ifdef CONFIG_MEMORY_FAILURE
> +#define ZSR_PG_HWPOISON(flag)	(1UL << flag)
> +#else
> +#define ZSR_PG_HWPOISON(flag)	0
> +#endif

__PG_HWPOISON

> +#define hr_queue_list_to_page(head) \
> +	compound_head(list_entry((head)->prev, struct page,\
> +		      hpage_reclaim_list))

I think you're better off subtracting 3*sizeof(struct page) than
loading from compound_head.

> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +/* Need the page lock if the page is not a newly allocated page. */
> +static void add_hpage_to_queue(struct page *page, struct mem_cgroup *memcg)
> +{
> +	struct hpage_reclaim *hr_queue;
> +	unsigned long flags;
> +
> +	if (READ_ONCE(memcg->thp_reclaim) == THP_RECLAIM_DISABLE)
> +		return;
> +
> +	page = compound_head(page);

Why do you think the caller might be passing in a tail page here?



  reply	other threads:[~2021-10-28 12:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-28 11:56 [RFC 0/6] Reclaim zero subpages of thp to avoid memory bloat Ning Zhang
2021-10-28 11:56 ` [RFC 1/6] mm, thp: introduce thp zero subpages reclaim Ning Zhang
2021-10-28 12:53   ` Matthew Wilcox [this message]
2021-10-29 12:16     ` ning zhang
2021-10-28 11:56 ` [RFC 2/6] mm, thp: add a global interface for zero subapges reclaim Ning Zhang
2021-10-28 11:56 ` [RFC 3/6] mm, thp: introduce zero subpages reclaim threshold Ning Zhang
2021-10-28 11:56 ` [RFC 4/6] mm, thp: introduce a controller to trigger zero subpages reclaim Ning Zhang
2021-10-28 11:56 ` [RFC 5/6] mm, thp: add some statistics for " Ning Zhang
2021-10-28 11:56 ` [RFC 6/6] mm, thp: add document " Ning Zhang
2021-10-28 14:13 ` [RFC 0/6] Reclaim zero subpages of thp to avoid memory bloat Kirill A. Shutemov
2021-10-29 12:07   ` ning zhang
2021-10-29 16:56     ` Yang Shi
2021-11-01  2:50       ` ning zhang
2021-10-29 13:38 ` Michal Hocko
2021-10-29 16:12   ` ning zhang
2021-11-01  9:20     ` Michal Hocko
2021-11-08  3:24       ` ning zhang

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=YXqdSgV9XmgOv3tp@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=ningzhang@linux.alibaba.com \
    --cc=vdavydov.dev@gmail.com \
    --cc=yuzhao@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox