From: Mel Gorman <mel@csn.ul.ie>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Minchan Kim <minchan.kim@gmail.com>,
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,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [RFC] Tight check of pfn_valid on sparsemem
Date: Tue, 13 Jul 2010 11:00:34 +0100 [thread overview]
Message-ID: <20100713100034.GF29885@csn.ul.ie> (raw)
In-Reply-To: <20100713094612.GF20590@n2100.arm.linux.org.uk>
On Tue, Jul 13, 2010 at 10:46:12AM +0100, Russell King - ARM Linux wrote:
> On Tue, Jul 13, 2010 at 10:37:00AM +0100, Mel Gorman wrote:
> > I prefer Kamezawa's suggestion of mapping on a ZERO_PAGE-like page full
> > of PageReserved struct pages because it would have better performance
> > and be more in line with maintaining the assumptions of the memory
> > model. If we go in this direction, I would strongly prefer it was an
> > ARM-only thing.
>
> As I've said, this is not possible without doing some serious page
> manipulation.
>
Yep, x86 used to do something like this for discontig. It wasn't pretty.
> Plus the pages that where there become unusable as they don't correspond
> with a PFN or obey phys_to_virt(). So there's absolutely no point to
> this.
>
> Now, why do we free the holes in the mem_map - because these holes can
> be extremely large. Every 512K of hole equates to one page of mem_map
> array.
Sure, the holes might be large but at least they are contiguous. Is
there ever a case where you have
512K_Valid 512K_Hole 512K_Valid 512K_Hole
or is it typically
512K_hole 512K_hole ...... 512K_Valid 512K_Valid etc
If holes are typically contiguos, memmap is not allocated in the first place
and the savings from punching holes in memmap in the latter configuration
are minimal.
I recognise if you have a 2M section with a hole in it, you are
potentially wasting 3 pages on unused memmap. If this is really a problem,
Minchan's modification to sparsemem to increase the size of mem_section on
CONFIG_ARCH_HAS_HOLES_MEMORYMODEL is a messy option. I say messy because
it only works if the hole is on either end of the section and it's adding
quirks to the memory model.
> Balance that against memory placed at 0xc0000000 physical on
> some platforms, and with PHYSMEM_BITS at 32 and SECTION_SIZE_BITS at
> 19 - well, you do the maths. The result is certainly not pretty.
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mel@csn.ul.ie>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Minchan Kim <minchan.kim@gmail.com>,
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,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [RFC] Tight check of pfn_valid on sparsemem
Date: Tue, 13 Jul 2010 11:00:34 +0100 [thread overview]
Message-ID: <20100713100034.GF29885@csn.ul.ie> (raw)
In-Reply-To: <20100713094612.GF20590@n2100.arm.linux.org.uk>
On Tue, Jul 13, 2010 at 10:46:12AM +0100, Russell King - ARM Linux wrote:
> On Tue, Jul 13, 2010 at 10:37:00AM +0100, Mel Gorman wrote:
> > I prefer Kamezawa's suggestion of mapping on a ZERO_PAGE-like page full
> > of PageReserved struct pages because it would have better performance
> > and be more in line with maintaining the assumptions of the memory
> > model. If we go in this direction, I would strongly prefer it was an
> > ARM-only thing.
>
> As I've said, this is not possible without doing some serious page
> manipulation.
>
Yep, x86 used to do something like this for discontig. It wasn't pretty.
> Plus the pages that where there become unusable as they don't correspond
> with a PFN or obey phys_to_virt(). So there's absolutely no point to
> this.
>
> Now, why do we free the holes in the mem_map - because these holes can
> be extremely large. Every 512K of hole equates to one page of mem_map
> array.
Sure, the holes might be large but at least they are contiguous. Is
there ever a case where you have
512K_Valid 512K_Hole 512K_Valid 512K_Hole
or is it typically
512K_hole 512K_hole ...... 512K_Valid 512K_Valid etc
If holes are typically contiguos, memmap is not allocated in the first place
and the savings from punching holes in memmap in the latter configuration
are minimal.
I recognise if you have a 2M section with a hole in it, you are
potentially wasting 3 pages on unused memmap. If this is really a problem,
Minchan's modification to sparsemem to increase the size of mem_section on
CONFIG_ARCH_HAS_HOLES_MEMORYMODEL is a messy option. I say messy because
it only works if the hole is on either end of the section and it's adding
quirks to the memory model.
> Balance that against memory placed at 0xc0000000 physical on
> some platforms, and with PHYSMEM_BITS at 32 and SECTION_SIZE_BITS at
> 19 - well, you do the maths. The result is certainly not pretty.
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
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:[~2010-07-13 10:00 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
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 [this message]
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=20100713100034.GF29885@csn.ul.ie \
--to=mel@csn.ul.ie \
--cc=akpm@linux-foundation.org \
--cc=arm-kernel@lists.infradead.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=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.