All of lore.kernel.org
 help / color / mirror / Atom feed
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Dave Hansen <dave@linux.vnet.ibm.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	linux@arm.linux.org.uk, Yinghai Lu <yinghai@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Shaohua Li <shaohua.li@intel.com>,
	Yakui Zhao <yakui.zhao@intel.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	arm-kernel@lists.infradead.org, kgene.kim@samsung.com,
	Mel Gorman <mel@csn.ul.ie>
Subject: Re: [RFC] Tight check of pfn_valid on sparsemem
Date: Wed, 14 Jul 2010 16:39:16 +0900	[thread overview]
Message-ID: <20100714163916.95afaf92.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <AANLkTilVVKdLNC0OJfVv5N5GGXL9bwXJfOLC5NHE-Qc4@mail.gmail.com>

On Wed, 14 Jul 2010 16:35:22 +0900
Minchan Kim <minchan.kim@gmail.com> wrote:

> On Wed, Jul 14, 2010 at 4:10 PM, KAMEZAWA Hiroyuki
> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > On Wed, 14 Jul 2010 15:44:41 +0900
> > Minchan Kim <minchan.kim@gmail.com> wrote:
> >
> >> Hi, Kame.
> >>
> >> On Wed, Jul 14, 2010 at 9:23 AM, KAMEZAWA Hiroyuki
> >> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> >> > On Wed, 14 Jul 2010 01:44:23 +0900
> >> > Minchan Kim <minchan.kim@gmail.com> wrote:
> >> >
> >> >> > If you _really_ can't make the section size smaller, and the vast
> >> >> > majority of the sections are fully populated, you could hack something
> >> >> > in.  We could, for instance, have a global list that's mostly readonly
> >> >> > which tells you which sections need to be have their sizes closely
> >> >> > inspected.  That would work OK if, for instance, you only needed to
> >> >> > check a couple of memory sections in the system.  It'll start to suck if
> >> >> > you made the lists very long.
> >> >>
> >> >> Thanks for advise. As I say, I hope Russell accept 16M section.
> >> >>
> >> >
> >> > It seems what I needed was good sleep....
> >> > How about this if 16M section is not acceptable ?
> >> >
> >> > == NOT TESTED AT ALL, EVEN NOT COMPILED ==
> >> >
> >> > register address of mem_section to memmap itself's page struct's pg->private field.
> >> > This means the page is used for memmap of the section.
> >> > Otherwise, the page is used for other purpose and memmap has a hole.
> >>
> >> It's a very good idea. :)
> >> But can this handle case that a page on memmap pages have struct page
> >> descriptor of hole?
> >> I mean one page can include 128 page descriptor(4096 / 32).
> > yes.
> >
> >> In there, 64 page descriptor is valid but remain 64 page descriptor is on hole.
> >> In this case, free_memmap doesn't free the page.
> >
> > yes. but in that case, there are valid page decriptor for 64pages of holes.
> > pfn_valid() should return true but PG_reserved is set.
> > (This is usual behavior.)
> >
> > My intention is that
> >
> >  - When all 128 page descriptors are unused, free_memmap() will free it.
> >   In that case, clear page->private of a page for freed page descriptors.
> >
> >  - When some of page descriptors are used, free_memmap() can't free it
> >   and page->private points to &mem_section. We may have memmap for memory
> >   hole but pfn_valid() is a function to check there is memmap or not.
> >   The bahavior of pfn_valid() is valid.
> >   Anyway, you can't free only half of page.
> 
> Okay. I missed PageReserved.
> Your idea seems to be good. :)
> 
> I looked at pagetypeinfo_showblockcount_print.
> It doesn't check PageReserved. Instead of it, it does ugly memmap_valid_within.
> Can't we remove it and change it with PageReserved?
> 
maybe. but I'm not sure how many archs uses CONFIG_ARCH_HAS_HOLES_MEMORYMODEL.
Because my idea requires to add arch-dependent hook, enhancement of pfn_valid()
happens only when an arch supports it. So, you may need a conservative path.

Anyway, I can't test the patch by myself. So, I pass ball to ARM guys.
Feel free to reuse my idea if you like.
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>

Thanks,
-Kame





WARNING: multiple messages have this Message-ID (diff)
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Dave Hansen <dave@linux.vnet.ibm.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	linux@arm.linux.org.uk, Yinghai Lu <yinghai@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Shaohua Li <shaohua.li@intel.com>,
	Yakui Zhao <yakui.zhao@intel.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	arm-kernel@lists.infradead.org, kgene.kim@samsung.com,
	Mel Gorman <mel@csn.ul.ie>
Subject: Re: [RFC] Tight check of pfn_valid on sparsemem
Date: Wed, 14 Jul 2010 16:39:16 +0900	[thread overview]
Message-ID: <20100714163916.95afaf92.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <AANLkTilVVKdLNC0OJfVv5N5GGXL9bwXJfOLC5NHE-Qc4@mail.gmail.com>

On Wed, 14 Jul 2010 16:35:22 +0900
Minchan Kim <minchan.kim@gmail.com> wrote:

> On Wed, Jul 14, 2010 at 4:10 PM, KAMEZAWA Hiroyuki
> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > On Wed, 14 Jul 2010 15:44:41 +0900
> > Minchan Kim <minchan.kim@gmail.com> wrote:
> >
> >> Hi, Kame.
> >>
> >> On Wed, Jul 14, 2010 at 9:23 AM, KAMEZAWA Hiroyuki
> >> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> >> > On Wed, 14 Jul 2010 01:44:23 +0900
> >> > Minchan Kim <minchan.kim@gmail.com> wrote:
> >> >
> >> >> > If you _really_ can't make the section size smaller, and the vast
> >> >> > majority of the sections are fully populated, you could hack something
> >> >> > in. A We could, for instance, have a global list that's mostly readonly
> >> >> > which tells you which sections need to be have their sizes closely
> >> >> > inspected. A That would work OK if, for instance, you only needed to
> >> >> > check a couple of memory sections in the system. A It'll start to suck if
> >> >> > you made the lists very long.
> >> >>
> >> >> Thanks for advise. As I say, I hope Russell accept 16M section.
> >> >>
> >> >
> >> > It seems what I needed was good sleep....
> >> > How about this if 16M section is not acceptable ?
> >> >
> >> > == NOT TESTED AT ALL, EVEN NOT COMPILED ==
> >> >
> >> > register address of mem_section to memmap itself's page struct's pg->private field.
> >> > This means the page is used for memmap of the section.
> >> > Otherwise, the page is used for other purpose and memmap has a hole.
> >>
> >> It's a very good idea. :)
> >> But can this handle case that a page on memmap pages have struct page
> >> descriptor of hole?
> >> I mean one page can include 128 page descriptor(4096 / 32).
> > yes.
> >
> >> In there, 64 page descriptor is valid but remain 64 page descriptor is on hole.
> >> In this case, free_memmap doesn't free the page.
> >
> > yes. but in that case, there are valid page decriptor for 64pages of holes.
> > pfn_valid() should return true but PG_reserved is set.
> > (This is usual behavior.)
> >
> > My intention is that
> >
> > A - When all 128 page descriptors are unused, free_memmap() will free it.
> > A  In that case, clear page->private of a page for freed page descriptors.
> >
> > A - When some of page descriptors are used, free_memmap() can't free it
> > A  and page->private points to &mem_section. We may have memmap for memory
> > A  hole but pfn_valid() is a function to check there is memmap or not.
> > A  The bahavior of pfn_valid() is valid.
> > A  Anyway, you can't free only half of page.
> 
> Okay. I missed PageReserved.
> Your idea seems to be good. :)
> 
> I looked at pagetypeinfo_showblockcount_print.
> It doesn't check PageReserved. Instead of it, it does ugly memmap_valid_within.
> Can't we remove it and change it with PageReserved?
> 
maybe. but I'm not sure how many archs uses CONFIG_ARCH_HAS_HOLES_MEMORYMODEL.
Because my idea requires to add arch-dependent hook, enhancement of pfn_valid()
happens only when an arch supports it. So, you may need a conservative path.

Anyway, I can't test the patch by myself. So, I pass ball to ARM guys.
Feel free to reuse my idea if you like.
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>

Thanks,
-Kame




--
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>

  reply	other threads:[~2010-07-14  7:44 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-12 15:53 [RFC] Tight check of pfn_valid on sparsemem Minchan Kim
2010-07-12 15:53 ` Minchan Kim
2010-07-12 23:59 ` Kukjin Kim
2010-07-12 23:59   ` Kukjin Kim
2010-07-13  3:19 ` KAMEZAWA Hiroyuki
2010-07-13  3:19   ` KAMEZAWA Hiroyuki
2010-07-13  4:11   ` Minchan Kim
2010-07-13  4:11     ` Minchan Kim
2010-07-13  4:23     ` KAMEZAWA Hiroyuki
2010-07-13  4:23       ` KAMEZAWA Hiroyuki
2010-07-13  6:04       ` Minchan Kim
2010-07-13  6:04         ` Minchan Kim
2010-07-13  6:40         ` KAMEZAWA Hiroyuki
2010-07-13  6:40           ` KAMEZAWA Hiroyuki
2010-07-13  8:06           ` Minchan Kim
2010-07-13  8:06             ` Minchan Kim
2010-07-13  8:03             ` KAMEZAWA Hiroyuki
2010-07-13  8:03               ` KAMEZAWA Hiroyuki
2010-07-13  7:20         ` Russell King - ARM Linux
2010-07-13  7:20           ` Russell King - ARM Linux
2010-07-13  7:34           ` KAMEZAWA Hiroyuki
2010-07-13  7:34             ` KAMEZAWA Hiroyuki
2010-07-13  7:58             ` KAMEZAWA Hiroyuki
2010-07-13  7:58               ` KAMEZAWA Hiroyuki
2010-07-13  8:02               ` KAMEZAWA Hiroyuki
2010-07-13  8:02                 ` KAMEZAWA Hiroyuki
2010-07-13 18:39                 ` Russell King - ARM Linux
2010-07-13 18:39                   ` Russell King - ARM Linux
2010-07-13 20:46                   ` Dave Hansen
2010-07-13 20:46                     ` Dave Hansen
2010-07-13  9:30 ` Johannes Weiner
2010-07-13  9:30   ` Johannes Weiner
2010-07-13 15:43   ` Minchan Kim
2010-07-13 15:43     ` Minchan Kim
2010-07-13 16:35     ` Dave Hansen
2010-07-13 16:35       ` Dave Hansen
2010-07-13 16:44       ` Minchan Kim
2010-07-13 16:44         ` Minchan Kim
2010-07-14  0:23         ` KAMEZAWA Hiroyuki
2010-07-14  0:23           ` KAMEZAWA Hiroyuki
2010-07-14  6:44           ` Minchan Kim
2010-07-14  6:44             ` Minchan Kim
2010-07-14  7:10             ` KAMEZAWA Hiroyuki
2010-07-14  7:10               ` KAMEZAWA Hiroyuki
2010-07-14  7:35               ` Minchan Kim
2010-07-14  7:35                 ` Minchan Kim
2010-07-14  7:39                 ` KAMEZAWA Hiroyuki [this message]
2010-07-14  7:39                   ` KAMEZAWA Hiroyuki
2010-07-14  7:50           ` Kukjin Kim
2010-07-14  7:50             ` Kukjin Kim
2010-07-14  8:09             ` KAMEZAWA Hiroyuki
2010-07-14  8:09               ` KAMEZAWA Hiroyuki
2010-07-13  9:37 ` Mel Gorman
2010-07-13  9:37   ` Mel Gorman
2010-07-13  9:46   ` Russell King - ARM Linux
2010-07-13  9:46     ` Russell King - ARM Linux
2010-07-13 10:00     ` Mel Gorman
2010-07-13 10:00       ` Mel Gorman

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=20100714163916.95afaf92.kamezawa.hiroyu@jp.fujitsu.com \
    --to=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=arm-kernel@lists.infradead.org \
    --cc=dave@linux.vnet.ibm.com \
    --cc=hannes@cmpxchg.org \
    --cc=hpa@zytor.com \
    --cc=kgene.kim@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mel@csn.ul.ie \
    --cc=minchan.kim@gmail.com \
    --cc=shaohua.li@intel.com \
    --cc=yakui.zhao@intel.com \
    --cc=yinghai@kernel.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.