Re: sparsemem support for mips with highmem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Christoph Lameter wrote:

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 to
reduce 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).


Well, I finally gotten around to turning the vmemmap on for our sparsemem on Mips.

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



[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux