All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Shi <alex.shi-KPsoFbNs7GizrGE5bRqYAgC/G2K4zDHf@public.gmane.org>
To: Hugh Dickins <hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org
Cc: Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	mgorman-3eNAlZScCAx27rWaFMvyedHuzzzSOjJt@public.gmane.org,
	tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	khlebnikov-XoJtRXgx1JseBXzfvpsJ4g@public.gmane.org,
	daniel.m.jordan-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org,
	yang.shi-KPsoFbNs7GizrGE5bRqYAgC/G2K4zDHf@public.gmane.org,
	willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
	shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
Subject: Re: [PATCH v7 00/10] per lruvec lru_lock for memcg
Date: Tue, 14 Jan 2020 17:29:17 +0800	[thread overview]
Message-ID: <39a72184-c864-4a40-49fd-c27893dd2002@linux.alibaba.com> (raw)
In-Reply-To: <641e4c96-c79f-fbdd-9762-f4608961423c-KPsoFbNs7GizrGE5bRqYAgC/G2K4zDHf@public.gmane.org>



在 2020/1/14 下午5:14, Alex Shi 写道:
> Anyway, although I didn't reproduced the bug. but I found a bug in my
> debug function:
> 	VM_BUG_ON_PAGE(lruvec_memcg(lruvec) != page->mem_cgroup, page);
> 
>  if !page->mem_cgroup, the bug could be triggered, so, seems it's a bug
> for debug function, not real issue. The 9th patch should be replaced by
> the following new patch. 

If !page->mem_cgroup, means the page is on root_mem_cgroup, so lurvec's
memcg is root_mem_cgroup, not NULL. that trigger the issue.


Hi Johannes,

So I have a question about the lock_page_memcg in this scenario, Should
we lock the page to root_mem_cgroup? or there is no needs as no tasks
move to a leaf memcg from root?

Thanks
Alex

WARNING: multiple messages have this Message-ID (diff)
From: Alex Shi <alex.shi@linux.alibaba.com>
To: Hugh Dickins <hughd@google.com>, hannes@cmpxchg.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
	cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, mgorman@techsingularity.net, tj@kernel.org,
	khlebnikov@yandex-team.ru, daniel.m.jordan@oracle.com,
	yang.shi@linux.alibaba.com, willy@infradead.org,
	shakeelb@google.com
Subject: Re: [PATCH v7 00/10] per lruvec lru_lock for memcg
Date: Tue, 14 Jan 2020 17:29:17 +0800	[thread overview]
Message-ID: <39a72184-c864-4a40-49fd-c27893dd2002@linux.alibaba.com> (raw)
In-Reply-To: <641e4c96-c79f-fbdd-9762-f4608961423c@linux.alibaba.com>



在 2020/1/14 下午5:14, Alex Shi 写道:
> Anyway, although I didn't reproduced the bug. but I found a bug in my
> debug function:
> 	VM_BUG_ON_PAGE(lruvec_memcg(lruvec) != page->mem_cgroup, page);
> 
>  if !page->mem_cgroup, the bug could be triggered, so, seems it's a bug
> for debug function, not real issue. The 9th patch should be replaced by
> the following new patch. 

If !page->mem_cgroup, means the page is on root_mem_cgroup, so lurvec's
memcg is root_mem_cgroup, not NULL. that trigger the issue.


Hi Johannes,

So I have a question about the lock_page_memcg in this scenario, Should
we lock the page to root_mem_cgroup? or there is no needs as no tasks
move to a leaf memcg from root?

Thanks
Alex


  parent reply	other threads:[~2020-01-14  9:29 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-25  9:04 [PATCH v7 00/10] per lruvec lru_lock for memcg Alex Shi
2019-12-25  9:04 ` [PATCH v7 01/10] mm/vmscan: remove unnecessary lruvec adding Alex Shi
2020-01-10  8:39   ` Konstantin Khlebnikov
2020-01-13  7:21     ` Alex Shi
2019-12-25  9:04 ` [PATCH v7 02/10] mm/memcg: fold lru_lock in lock_page_lru Alex Shi
     [not found]   ` <1577264666-246071-3-git-send-email-alex.shi-KPsoFbNs7GizrGE5bRqYAgC/G2K4zDHf@public.gmane.org>
2020-01-10  8:49     ` Konstantin Khlebnikov
2020-01-10  8:49       ` Konstantin Khlebnikov
     [not found]       ` <36d7e390-a3d1-908c-d181-4a9e9c8d3d98-XoJtRXgx1JseBXzfvpsJ4g@public.gmane.org>
2020-01-13  9:45         ` Alex Shi
2020-01-13  9:45           ` Alex Shi
2020-01-13  9:55           ` Konstantin Khlebnikov
     [not found]             ` <2ba8a04e-d8e0-1d50-addc-dbe1b4d8e0f1-XoJtRXgx1JseBXzfvpsJ4g@public.gmane.org>
2020-01-13 12:47               ` Alex Shi
2020-01-13 12:47                 ` Alex Shi
     [not found]                 ` <a095d80d-8e34-c84f-e4be-085a5aae1929-KPsoFbNs7GizrGE5bRqYAgC/G2K4zDHf@public.gmane.org>
2020-01-13 16:34                   ` Matthew Wilcox
2020-01-13 16:34                     ` Matthew Wilcox
2020-01-14  9:20                     ` Alex Shi
2019-12-25  9:04 ` [PATCH v7 03/10] mm/lru: replace pgdat lru_lock with lruvec lock Alex Shi
2019-12-25  9:04   ` Alex Shi
2020-01-13 15:41   ` Daniel Jordan
2020-01-13 15:41     ` Daniel Jordan
     [not found]     ` <20200113154116.mwly5hl5yfvjkzl2-S51bK0XF4qpuJJETbFA3a0B3C2bhBk7L0E9HWUfgJXw@public.gmane.org>
2020-01-14  6:33       ` Alex Shi
2020-01-14  6:33         ` Alex Shi
2019-12-25  9:04 ` [PATCH v7 04/10] mm/lru: introduce the relock_page_lruvec function Alex Shi
2019-12-25  9:04 ` [PATCH v7 05/10] mm/mlock: optimize munlock_pagevec by relocking Alex Shi
2019-12-25  9:04 ` [PATCH v7 06/10] mm/swap: only change the lru_lock iff page's lruvec is different Alex Shi
2019-12-25  9:04 ` [PATCH v7 07/10] mm/pgdat: remove pgdat lru_lock Alex Shi
2019-12-25  9:04 ` [PATCH v7 08/10] mm/lru: revise the comments of lru_lock Alex Shi
2019-12-25  9:04   ` Alex Shi
2019-12-25  9:04 ` [PATCH v7 09/10] mm/lru: add debug checking for page memcg moving Alex Shi
2019-12-25  9:04 ` [PATCH v7 10/10] mm/memcg: add debug checking in lock_page_memcg Alex Shi
2019-12-31 23:05 ` [PATCH v7 00/10] per lruvec lru_lock for memcg Andrew Morton
2020-01-02 10:21   ` Alex Shi
2020-01-02 10:21     ` Alex Shi
2020-01-10  2:01     ` Alex Shi
     [not found]       ` <d2efad94-750b-3298-8859-84bccc6ecf06-KPsoFbNs7GizrGE5bRqYAgC/G2K4zDHf@public.gmane.org>
2020-01-13  8:48         ` Hugh Dickins
2020-01-13  8:48           ` Hugh Dickins
     [not found]           ` <alpine.LSU.2.11.2001130032170.1103-fupSdm12i1nKWymIFiNcPA@public.gmane.org>
2020-01-13 12:45             ` Alex Shi
2020-01-13 12:45               ` Alex Shi
     [not found]               ` <24d671ac-36ef-8883-ad94-1bd497d46783-KPsoFbNs7GizrGE5bRqYAgC/G2K4zDHf@public.gmane.org>
2020-01-13 20:20                 ` Hugh Dickins
2020-01-13 20:20                   ` Hugh Dickins
2020-01-14  9:14                   ` Alex Shi
     [not found]                     ` <641e4c96-c79f-fbdd-9762-f4608961423c-KPsoFbNs7GizrGE5bRqYAgC/G2K4zDHf@public.gmane.org>
2020-01-14  9:29                       ` Alex Shi [this message]
2020-01-14  9:29                         ` Alex Shi

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=39a72184-c864-4a40-49fd-c27893dd2002@linux.alibaba.com \
    --to=alex.shi-kpsofbns7gizrge5brqyagc/g2k4zdhf@public.gmane.org \
    --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=daniel.m.jordan-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
    --cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
    --cc=hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=khlebnikov-XoJtRXgx1JseBXzfvpsJ4g@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
    --cc=mgorman-3eNAlZScCAx27rWaFMvyedHuzzzSOjJt@public.gmane.org \
    --cc=shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=yang.shi-KPsoFbNs7GizrGE5bRqYAgC/G2K4zDHf@public.gmane.org \
    /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.