linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Qian Cai <cai@lca.pw>
To: Vlastimil Babka <vbabka@suse.cz>,
	"Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org,  linux-kernel@vger.kernel.org,
	kasan-dev@googlegroups.com,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Matthew Wilcox <willy@infradead.org>,
	Mel Gorman <mgorman@techsingularity.net>,
	Michal Hocko <mhocko@kernel.org>,
	Dmitry Vyukov <dvyukov@google.com>,
	Walter Wu <walter-zh.wu@mediatek.com>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>
Subject: Re: [PATCH v2 2/3] mm, page_owner: decouple freeing stack trace from debug_pagealloc
Date: Tue, 01 Oct 2019 09:18:10 -0400	[thread overview]
Message-ID: <1569935890.5576.255.camel@lca.pw> (raw)
In-Reply-To: <cb02d61c-eeb1-9875-185d-d3dd0e0b2424@suse.cz>

On Tue, 2019-10-01 at 14:35 +0200, Vlastimil Babka wrote:
> On 10/1/19 2:32 PM, Vlastimil Babka wrote:
> > On 10/1/19 2:26 PM, Qian Cai wrote:
> > > On Tue, 2019-10-01 at 14:51 +0300, Kirill A. Shutemov wrote:
> > > > On Tue, Oct 01, 2019 at 10:07:44AM +0200, Vlastimil Babka wrote:
> > > > > On 10/1/19 1:49 AM, Qian Cai wrote:
> > > > 
> > > > DEBUG_PAGEALLOC is much more intrusive debug option. Not all architectures
> > > > support it in an efficient way. Some require hibernation.
> > > > 
> > > > I don't see a reason to tie these two option together.
> > > 
> > > Make sense. How about page_owner=on will have page_owner_free=on by default?
> > > That way we don't need the extra parameter.
> > 
> >  
> > There were others that didn't want that overhead (memory+cpu) always. So the
> > last version is as flexible as we can get, IMHO, before approaching bikeshed
> > territory. It's just another parameter.
> 
> Or suggest how to replace page_owner=on with something else (page_owner=full?)
> and I can change that. But I don't want to implement a variant where we store only
> the freeing stack, though.

I don't know why you think it is a variant. It sounds to me it is a natural
extension that belongs to page_owner=on that it could always store freeing stack
to help with debugging. Then, it could make implementation easier without all
those different  combinations you mentioned in the patch description that could
confuse anyone.

If someone complains about the overhead introduced to the existing page_owner=on
users, then I think we should have some number to prove that say how much
overhead there by storing freeing stack in page_owner=on, 10%, 50%?


  reply	other threads:[~2019-10-01 13:18 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-30 12:29 [PATCH v2 0/3] followups to debug_pagealloc improvements through page_owner Vlastimil Babka
2019-09-30 12:29 ` [PATCH v2 1/3] mm, page_owner: fix off-by-one error in __set_page_owner_handle() Vlastimil Babka
2019-09-30 12:29 ` [PATCH v2 2/3] mm, page_owner: decouple freeing stack trace from debug_pagealloc Vlastimil Babka
2019-09-30 12:49   ` Qian Cai
2019-09-30 21:39     ` Vlastimil Babka
2019-09-30 23:49       ` Qian Cai
2019-10-01  8:07         ` Vlastimil Babka
2019-10-01 11:51           ` Kirill A. Shutemov
2019-10-01 12:26             ` Qian Cai
2019-10-01 12:31               ` Kirill A. Shutemov
2019-10-01 12:32               ` Vlastimil Babka
2019-10-01 12:35                 ` Vlastimil Babka
2019-10-01 13:18                   ` Qian Cai [this message]
2019-10-01 14:15                     ` Vlastimil Babka
2019-10-01 11:35       ` Kirill A. Shutemov
2019-09-30 12:29 ` [PATCH v2 3/3] mm, page_owner: rename flag indicating that page is allocated Vlastimil Babka
2019-09-30 12:49   ` Vlastimil Babka

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=1569935890.5576.255.camel@lca.pw \
    --to=cai@lca.pw \
    --cc=akpm@linux-foundation.org \
    --cc=aryabinin@virtuozzo.com \
    --cc=dvyukov@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=vbabka@suse.cz \
    --cc=walter-zh.wu@mediatek.com \
    --cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).