All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan.kim@gmail.com>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: 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>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [RFC] Tight check of pfn_valid on sparsemem
Date: Wed, 14 Jul 2010 01:44:23 +0900	[thread overview]
Message-ID: <20100713164423.GC2815@barrios-desktop> (raw)
In-Reply-To: <1279038933.10995.9.camel@nimitz>

Hi, Dave. 

On Tue, Jul 13, 2010 at 09:35:33AM -0700, Dave Hansen wrote:
> On Wed, 2010-07-14 at 00:43 +0900, Minchan Kim wrote:
> > 3 is not a big deal than 2 about memory usage.
> > If the system use memory space fully(MAX_PHYSMEM_BITS 31), it just consumes
> > 1024(128 * 8) byte. So now I think best solution is 2. 
> > 
> > Russell. What do you think about it? 
> 
> I'm not Russell, but I'll tell you what I think. :)
> 

No problem. :)

> Make the sections 16MB.  You suggestion to add the start/end pfns

I hope so. 

> _doubles_ the size of the structure, and its size overhead.  We have
> systems with a pretty tremendous amount of memory with 16MB sections.

Yes. it does in several GB server system.

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

> 
> -- Dave
> 

-- 
Kind regards,
Minchan Kim

WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan.kim@gmail.com>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: 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>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [RFC] Tight check of pfn_valid on sparsemem
Date: Wed, 14 Jul 2010 01:44:23 +0900	[thread overview]
Message-ID: <20100713164423.GC2815@barrios-desktop> (raw)
In-Reply-To: <1279038933.10995.9.camel@nimitz>

Hi, Dave. 

On Tue, Jul 13, 2010 at 09:35:33AM -0700, Dave Hansen wrote:
> On Wed, 2010-07-14 at 00:43 +0900, Minchan Kim wrote:
> > 3 is not a big deal than 2 about memory usage.
> > If the system use memory space fully(MAX_PHYSMEM_BITS 31), it just consumes
> > 1024(128 * 8) byte. So now I think best solution is 2. 
> > 
> > Russell. What do you think about it? 
> 
> I'm not Russell, but I'll tell you what I think. :)
> 

No problem. :)

> Make the sections 16MB.  You suggestion to add the start/end pfns

I hope so. 

> _doubles_ the size of the structure, and its size overhead.  We have
> systems with a pretty tremendous amount of memory with 16MB sections.

Yes. it does in several GB server system.

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

> 
> -- Dave
> 

-- 
Kind regards,
Minchan Kim

--
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-13 16: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 [this message]
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
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=20100713164423.GC2815@barrios-desktop \
    --to=minchan.kim@gmail.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=kamezawa.hiroyu@jp.fujitsu.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=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.