lkml.org 
[lkml]   [2006]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [MODSLAB 3/7] A Kmalloc subsystem
On Fri, 18 Aug 2006 11:44:22 -0700 (PDT)
Christoph Lameter <clameter@sgi.com> wrote:
> > and usual SPARSEMEM, (not EXTREME)
> > --
> > page = mem_section[(pfn >> SECTION_SHIFT)].mem_map + pfn
> > --
> > need one table look up. maybe not very big.
>
> Bigger than a cacheline that can be kept in the cache?

powerpc's section size is 16Mbytes. so table itself is bigger than cacheline.
And powerpc doesn't have DISCONTIG configuration.

> > with SPARSEMEM_EXTREME
> > --
> > page = mem_section[(pfn >> SECTION_SHIFT)][(pfn & MASK)].mem_map + pfn
> > --
> > need one (big)table look up.
>
> Owww... Cache issues.
>
> Could we do the lookup using a sparse virtually mapped table like on
> IA64. Then align section shift to whatever page table is in place (on
> platforms that require page tables and IA64 could continue to use its
> special handler)?
>
> Then page could be reached via
>
> page = vmem_map + pfn
>
> again ?
>

In early days of implementing SPARSEMEM, I tried vmem_map + SPARSEMEM.
But it was very complicated.....so it was dropped.
Before retrying, I think performance/profile test with each memory model should
be done.
Considering ia64, an advantage of SPARSEMEM is (just?) memory hotplug.
If people need extreme performance, they can select DISCONTIGMEM.

But powerpc(NUMA) people has only SPARSEMEM. So test on powerpc will be
necessary, anyway.(of course, they doesn't have vmem_map)

-Kame





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-08-18 21:17    [from the cache]
©2003-2011 Jasper Spaans