|To:||Christoph Lameter <email@example.com>|
|Subject:||Re: sparsemem support for mips with highmem|
|From:||Michael Sundius <firstname.lastname@example.org>|
|Date:||Fri, 16 Jan 2009 13:46:21 -0800|
|Authentication-results:||rtp-dkim-2; header.Fromemail@example.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );|
|Cc:||Dave Hansen <firstname.lastname@example.org>, Randy Dunlap <email@example.com>, "Sundius, Michael" <Michael.firstname.lastname@example.org>, Thomas Bogendoerfer <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Andy Whitcroft <email@example.com>, firstname.lastname@example.org|
|Dkim-signature:||v=1; a=rsa-sha256; q=dns/txt; l=2460; t=1232142390; x=1233006390; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; email@example.com; z=From:=20Michael=20Sundius=20<firstname.lastname@example.org> |Subject:=20Re=3A=20sparsemem=20support=20for=20mips=20with =20highmem |Sender:=20 |To:=20Christoph=20Lameter=20<email@example.com>; bh=okOxMMyILXhoHPpyJ22h2rSlK4WI+Fu9ej9H9Pb4gSw=; b=nqLHTii4OXSx9+1HNnhLebvVIoyuzwbvzH+jEE/rcazDXBUsd0C2+/a+rE Tduh7QlMkvOEsOwTz9cNOf2G1C+Bz0RP9M52hIw3zygb5gIbTKntIKU8Snni IWcE/jmBz/;|
|References:||<48A4AC39.firstname.lastname@example.org> <1218753308.23641.56.camel@nimitz> <48A4C542.email@example.com> <20080815080331.GA6689@alpha.franken.de> <1218815299.23641.80.camel@nimitz> <48A5AADE.firstname.lastname@example.org> <20080815163302.GA9846@alpha.franken.de> <48A5B9F1.email@example.com> <1218821875.23641.103.camel@nimitz> <48A5C831.firstname.lastname@example.org> <email@example.com> <48A9E89C.firstname.lastname@example.org> <1219094865.23641.118.camel@nimitz> <48A9EAA9.email@example.com>|
|User-agent:||Thunderbird 188.8.131.52 (X11/20080501)|
Christoph Lameter wrote:
Well, I finally gotten around to turning the vmemmap on for our sparsemem on Mips.Dave Hansen wrote: > On Mon, 2008-08-18 at 16:24 -0500, Christoph Lameter wrote:>> This overhead can be avoided by configuring sparsemem to use a virtual vmemmap >> (CONFIG_SPARSEMEM_VMEMMAP). In that case it can be used for non NUMA since the>> overhead is less than even FLATMEM. > > Is that all it takes these days, or do you need some other arch-specific > code to help out?Some information is in mm/sparse-vmemmap.c. Simplest configuration is to use vmalloc for the populate function. Otherwise the arch can do what it wants toreduce the overhead of virtual mappings (in the x86 case we use a 2M TLB entry, and since 2M TLBs are also used for the 1-1 physical mapping the overhead is the same as for 1-1 mappings).
I have a question about what you said above and how that applies to mips.you said that the simplest configuration is to use vmalloc for the populate function. could you expand on that? (i didn't see that the populate function used vmalloc or maybe
we are talking about a different populate function).I've noticed that from looking at the kernel, only 64 bit processors or at least processors that use a 3 level page table have the vmemmap_populate() function implemented.
in looking at the function vmemmap_populate_basepages() (called by most vmemmap_populate funcs)
it seems to create a 3 levelpage table. not sure what my question here is, but maybe what do I have to do to make this work w/ mips which i understand uses only 2 levels can I just take out the part of
the function that sets up the middle level table? Has anyone done this on mips? mike- - - - - Cisco - - - - - This e-mail and any attachments may contain information which is confidential, proprietary, privileged or otherwise protected by law. The information is solely intended for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [PATCH] au1000: convert to using gpiolib, Manuel Lauss|
|Next by Date:||[RFC PATCH] au1k_ir.c: convert to platform device, Manuel Lauss|
|Previous by Thread:||Re: [PATCH] tx4939ide: Do not use zero count PRD entry, Sergei Shtylyov|
|Next by Thread:||Re: sparsemem support for mips with highmem, Christoph Lameter|
|Indexes:||[Date] [Thread] [Top] [All Lists]|