From: Andrew Morton <akpm@linux-foundation.org>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Dave Hansen <dave@sr71.net>, Mel Gorman <mgorman@suse.de>,
Johannes Weiner <hannes@cmpxchg.org>,
Minchan Kim <minchan@kernel.org>,
Alexander Nyberg <alexn@dsv.su.se>,
Dave Hansen <dave@linux.vnet.ibm.com>,
Michal Nazarewicz <mina86@mina86.com>,
Jungsoo Son <jungsoo.son@lge.com>, Ingo Molnar <mingo@redhat.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/5] mm/page_ext: resurrect struct page extending code for debugging
Date: Thu, 13 Nov 2014 12:40:35 -0800 [thread overview]
Message-ID: <20141113124035.35bc5bb743affddf7f425825@linux-foundation.org> (raw)
In-Reply-To: <20141113064035.GB18369@js1304-P5Q-DELUXE>
On Thu, 13 Nov 2014 15:40:35 +0900 Joonsoo Kim <iamjoonsoo.kim@lge.com> wrote:
> On Wed, Nov 12, 2014 at 08:33:40AM -0800, Dave Hansen wrote:
> > On 11/12/2014 12:27 AM, Joonsoo Kim wrote:
> > > @@ -1092,6 +1096,14 @@ struct mem_section {
> > >
> > > /* See declaration of similar field in struct zone */
> > > unsigned long *pageblock_flags;
> > > +#ifdef CONFIG_PAGE_EXTENSION
> > > + /*
> > > + * If !SPARSEMEM, pgdat doesn't have page_ext pointer. We use
> > > + * section. (see page_ext.h about this.)
> > > + */
> > > + struct page_ext *page_ext;
> > > + unsigned long pad;
> > > +#endif
> >
> > Will the distributions be amenable to enabling this? If so, I'm all for
> > it if it gets us things like page_owner at runtime.
>
> Yes, I hope so.
> At least, I can make it default to our product. But, how distributions
> will do is beyond my power. :)
>
>From my reading of the code, the overhead is very low if nobody is
using it. In which case things should be OK and we can perhaps do away
with CONFIG_PAGE_EXTENSION altogether.
But my reading of the code may be wrong. It is very poorly documented.
As far as I can tell, invoke_need_callbacks() works out whether there
are any clients of this feature and if not, we avoid allocating that
huge chunk of memory.
And the way we register clients is to enter a pointer into the global
page_ext_ops[]. So this requires a kernel rebuild anyway, so there's
no point in distros enabling CONFIG_PAGE_EXTENSION. The way to do this
is for CONFIG_PAGE_OWNER (for example) to `select'
CONFIG_PAGE_EXTENSION.
It's unclear to me why invoke_need_callbacks() walks the page_ext_ops[]
entries, inspecting them. Perhaps this is so that clients of
CONFIG_PAGE_EXTENSION can be enabled/disabled at boot time, dunno.
Please, can we get all this design and behaviour appropriately
documented in the code and changelogs?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-11-13 20:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-12 8:27 [RFC PATCH 0/5] Resurrect and use struct page extension for some debugging features Joonsoo Kim
2014-11-12 8:27 ` [RFC PATCH 1/5] mm/page_ext: resurrect struct page extending code for debugging Joonsoo Kim
2014-11-12 16:33 ` Dave Hansen
2014-11-13 6:40 ` Joonsoo Kim
2014-11-13 20:40 ` Andrew Morton [this message]
2014-11-14 0:14 ` Joonsoo Kim
2014-11-12 8:27 ` [RFC PATCH 2/5] mm/debug-pagealloc: prepare boottime configurable on/off Joonsoo Kim
2014-11-12 8:27 ` [RFC PATCH 3/5] mm/debug-pagealloc: make debug-pagealloc boottime configurable Joonsoo Kim
2014-11-12 8:27 ` [RFC PATCH 4/5] stacktrace: support snprint Joonsoo Kim
2014-11-12 8:27 ` [RFC PATCH 5/5] mm/page_owner: keep track of page owners Joonsoo Kim
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=20141113124035.35bc5bb743affddf7f425825@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=alexn@dsv.su.se \
--cc=dave@linux.vnet.ibm.com \
--cc=dave@sr71.net \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=jungsoo.son@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mina86@mina86.com \
--cc=minchan@kernel.org \
--cc=mingo@redhat.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