lkml.org 
[lkml]   [2002]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: consequences of lowering "MAX_LOW_MEM"?
>> In 2.4.x (currently using 2.4.18), for PPC, there is a value for
>> "MAX_LOW_MEM" defined in "arch/ppc/mm/pgtable.c" as 768MB RAM. Any
>> memory above 768MB is considered "high" memory. Now our problem is
>> that we have 1024MB of onboard RAM on our card. I do *NOT* wish to
>> compile with "CONFIG_HIGHMEM" set to true (see below for why), but i
>> do wish to have full use of the 1024MB of RAM onboard, or at least
>> 992MB which is the minimum for our app.
>> So what I did was just change "MAX_LOW_MEM" to be 0x3E000000
>> (0x30000000), ie. change it to 992 from 768. I recompiled and tested
>> our application. Things seemed to be running normal with a max of
>> 992MB of RAM.
>>
>> Is this a potential problem, or will this cause some lurking bug that
>> anyone can think of? (ie. I'm sure "MAX_LOW_MEM" was set to 768MB for
>> a reason, but what is that reason). We don't want to move higher
>> than 1Gig RAM for now, so are we going to be okay doing what I
>> describe above? Any suggestions or comments as to why that's a very
>> bad idea would be greatly appreciated. Again, this is for a
>> PPC-specific board, I'm not sure what the x86 architecture's low
>> memory max is.

I think you'll find yourself with no virtual address space left to
do vmalloc / fixmap / kmap type stuff. Or at least you would on i386,
I presume it's the same for ppc. Sounds like you may have left
yourself enough space for fixmap & kmap, but any calls to vmalloc
will probably fail ?

M.

-
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: 2005-03-22 13:28    [W:0.096 / U:0.492 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site