Re: "things are about right" kernel test?

From: Maciej Zenczykowski
Date: Fri Nov 14 2003 - 12:56:51 EST


> I recall some people mentioning that if they have 1GiB of RAM, something
> (I forget what) performs badly. They set it to 900-some MiB, and then
> things work better. A test for that with built-in tips for solving the
> problem might be helpful.

Regarding the 1GB limit (or rather 1024-128 MB = 896 MB limit), this is
due to Kernel space beginning at 0xC0000000 (giving 1GB of ram for the
kernel from 0xC0000000..0xFFFFFFFF) of which 128 MB are reserved for
vmalloc and other uses... The question is: is there any reason why this
0xC0000000 couldn't be lowered by 128 MB (to 0xBE000000)?

This would allow using the full 1GB of Ram without using highmem. As I
understand it using highmem does involve some performance loss.
Effectively for me this means that PAGE_OFFSET in include/asm-i386/page.h
should be set to either 4GB-128MB-512MB (allowing 512MB ram without
highmem) or 4GB-128MB-1GB (allowing 1GB ram without highmem). Afterall
I'd expect real life memory configurations are for the majority power of 2
situations - which means you're likely to hit 512MB or 1GB - having the
limit at 896 MB seems pointless. 1GB memory configurations are becoming
more and more common and they are just barely above the highmem cut-off
point, changeing it would fix all the 1GB problems and not really affect
anything else (like those machines with even more RAM). Sure this limits
the memory available for user processes (from 3 GB to 2.875 GB), but then
the true limit in user space (if I understand this correctly) is that mmap
starts mapping at 1GB anyway [TASK_UNMAPPED_BASE = TASK_SIZE/3 =
PAGE_OFFSET/3 = 1GB currently], if this was changed to a lower value
(likely a static 16MB or even 1MB+64KB would be OK) then we'd effectively
increase the amount of mmaping you could do (sure this doesn't affect brk,
oh well.)

Comments,

MaZe.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/