On 05.06.2009 17:09, Myles Watson wrote:
I'm not sure it gets any easier to understand or less cryptic by calling the amount of RAM end of RAM and printing it twice?
Actually, it's the end of RAM. On my 4 GB machine, tom_k is 0x00500000 which is 5*1024*1024. The hole starts at 3 GB in that configuration. However, printing it twice serves no purpose. I'll fix and resend.
Turns out it once prints the unadjusted RAM end and once the adjusted RAM end, so killing off either of the prinks is not advisable.
I think it makes it easier to review patches like this (that only change debugging output) if you include before and after log snippets.
Old messages for my machine with 5 GB: RAM: 0x00400000 kB Ram3 [...] Initializing memory: done RAM: 0x00500000 kB
New messages: RAM end at 0x00400000 kB, hole starts at 0x00000000 kB Adjusting lower RAM end Lower RAM end at 0x003f0000 kB Ram3 [...] Initializing memory: done Handling memory hole at 0x00300000 (default) RAM end at 0x00500000 kB, hole starts at 0x00300000 kB Handling memory mapped above 4 GB Upper RAM end at 0x00500000 kB Correcting memory amount mapped below 4 GB Adjusting lower RAM end Lower RAM end at 0x00300000 kB
I hope this helps understand my patch better.
Regards, Carl-Daniel