linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: ning zhang <ningzhang@linux.alibaba.com>
To: Matthew Wilcox <willy@infradead.org>
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: Fri, 29 Oct 2021 20:16:00 +0800	[thread overview]
Message-ID: <0ee9c9f6-4d56-a8dd-c922-0d4fc456cbf0@linux.alibaba.com> (raw)
In-Reply-To: <YXqdSgV9XmgOv3tp@casper.infradead.org>


在 2021/10/28 下午8:53, Matthew Wilcox 写道:
> 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?

Thanks for the comments!  I will modify it.



  reply	other threads:[~2021-10-29 12:16 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
2021-10-29 12:16     ` ning zhang [this message]
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=0ee9c9f6-4d56-a8dd-c922-0d4fc456cbf0@linux.alibaba.com \
    --to=ningzhang@linux.alibaba.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=vdavydov.dev@gmail.com \
    --cc=willy@infradead.org \
    --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