Mandrake Linux RAM handling - I can't find anything that says how Linux handles 1gb RAM...

[yooz2BTester]

Maybe I'm looking in the wrong places (wouldn't be the first time!), but I haven't found any specs or reviews that say how well it handles large RAM. I found lots of information about how Windows handles (or doesn't handle) it. Anyone have any idea?

I've just finished my new XP1500+ box and I might be able to afford another 512MB Ram...if it's worth it.

 

[kylef]

It's not worth it right now. Wait until RAM prices come back down to their summer-2000 level.

If you're using a post-2.4.11 kernel, then Linux does a great job managing memory and there is even less of an incentive to upgrade from 512 megs of RAM to 1 gig, other than bragging rights

I had a gigabyte on a FreeBSD box that worked wonderfully, but I NEEDED it because I was running a custom application that used about 600 megs (a gigabit uplink network protocol sniffer). Unless you have applications that need that amount of RAM, you WILL NOT see a difference in performance between 512 megs and 1 gigabyte of RAM under Linux.

 

[manly]

I have 1 GB of RAM on my box.

It was dirt cheap, and I actually have some hungry apps that use the memory.

I'd say in general, Linux handles large amounts of memory pretty well. Like kylef said though, RAM prices have spiked up, so don't get it unless you need it.

 

[Bremen]

Linux will handle up to 2 GB of RAM at present. Companies like IBM and other hardware vendors are pushing for even larger memory support, however Linus is resistant to adding it.
Of course Linus once said Linux would never support 2 GB of RAM, you think he'd have learned after Gates prediction of 640k being the max anyone would ever need.

 

[Priit]

AFAIK that 2Gb was limit with old 2.2 or 2.0 series kernel. 2.4 kernel docs are saying that it supports up to 64Gb RAM...

 

[Nothinman]

Linux supports Intel's PAE hack that allows them to use 64G of memory on 32-bit processors and 64-bit processors which can natively address tons of memory, but at about 16G the kernel chokes, it runs out of kernel memory because the struct_page is so big it uses all the memory set aside for the kernel. There is work to make struct_page smaller and other things that'll let Linux use more memory in 2.5 and 2.6.

Companies like IBM and other hardware vendors are pushing for even larger memory support, however Linus is resistant to adding it.

He's resistant because adding support for those large boxes adds overhead that makes smaller boxes run slower. It's the same thing with ultra-fine grained SMP locking, makes it use 8, 16, 32, etc processors really effeciently but makes 1 or 2 processor boxes run slower like in Solaris. As long as it's done with no bad impact on other setups there's no problems.

 

[n0cmonkey]

<< Companies like IBM and other hardware vendors are pushing for even larger memory support, however Linus is resistant to adding it.

He's resistant because adding support for those large boxes adds overhead that makes smaller boxes run slower. It's the same thing with ultra-fine grained SMP locking, makes it use 8, 16, 32, etc processors really effeciently but makes 1 or 2 processor boxes run slower like in Solaris. As long as it's done with no bad impact on other setups there's no problems. >>



They could easily start a patch branch, or whatever you want to call it, to better support the big iron.

On my dual p3 machine I have 1GB of ram and I had to recompile my kernel to handle that much. For some reason the default maxed out at 960MB on my machine. I think that was the 2.2 kernel though.

 

[Nothinman]

They could easily start a patch branch, or whatever you want to call it, to better support the big iron.

Most do maintain patches until Linus excepts them, the problem is maintaining a patch against Linux which is a very moving target. And there's a lot of people that feel if it's not in the main kernel tree it's not supported.

And right now HIGHMEM support isn't that great, many people with 1G of memory will leave the HIGHMEM support out and just use the ~960M Linux can see without it because it's more stable.

 

[n0cmonkey]

<< They could easily start a patch branch, or whatever you want to call it, to better support the big iron.

Most do maintain patches until Linus excepts them, the problem is maintaining a patch against Linux which is a very moving target. And there's a lot of people that feel if it's not in the main kernel tree it's not supported. >>



I can see that. Going to Linus and friends with a patched kernel could lead to problems. Is the error coming from the patches, the kernel, or the kernel because of the patches?



<< And right now HIGHMEM support isn't that great, many people with 1G of memory will leave the HIGHMEM support out and just use the ~960M Linux can see without it because it's more stable. >>



I havent noticed any problems but my machine isnt doing a whole lot right now.

 

[Nothinman]

I havent noticed any problems but my machine isnt doing a whole lot right now.

I'm pretty sure most of the problems are driver related, you might be lucky and not be using any HIGHMEM-dumb drivers =)

I can see that. Going to Linus and friends with a patched kernel could lead to problems. Is the error coming from the patches, the kernel, or the kernel because of the patches?

Exactly, they've already added a 'tainted' flag to the kernel so they can tell if you've got any closed-source modules loaded from the Oops output, because if you do they have no way of knowing if the problem is Linux or the module. And if you have something like VMWare or nVidia's module loaded you need to go to them for help.

Also for maintainability, to support normal 32-bit memory access, 4G on 32-bit machines, PAE for 64G on 32-bit machines, NUMA, etc would require a lot of spaghetti code full of #ifdefs unless done extremely well, and I think Linus is waiting for the extremly well done patch =)