hi,

can anybody tell me what is highmemory and CONFIG_HIGHMEM are in linux?

in what cases is this flag CONFIG_HIGHMEM set and in what cases its not set

regards
Sindhu

Read about memory management in Linux kernels

If you use this, additional 128MB of RAM is accessible for processes.
It is advised to NOT use this.

uhelp: why it is advised not to use highmem? You even didn't asked what architecture and how much memory have sindhumaheswari! How can you advise him not to use it, if you don't know his architecture not his memory size?

sindhumaheswari:
HIGHMEM is simply mechanism to allow you to use more then 1GiB of RAM on 32b architectures (I think it applies only to IA32, but I am not sure).
Plain HighMem allows you to use 3-4GiB of RAM on IA32 (it depends on size of your RAM, chipset, BIOS, PCI devices, port and memory mappings and maybe even more). Typically you should get 3 - 3.25 - 3.5 GiB of RAM (I have laptop, which have physically 4GiB of RAM, but only 3GiB is available to me, even with HighMem64G). Some chipsets do allow quite a lot (like AMD760) up to 3.75GiB and as far as I know it is most you can get.
There is HighMem64G (you need PAE and PSE36 support in CPU for it) which allow up to 64GiB.

There is overhead when using HighMem (both in computing and memory size terms). For HighMem (4G) there is second level of page-tables needed, which obviously would still small portion of your RAM. For HighMem64G three levels of page-tables are needed, so overhead is growing. It is not advised to use HighMem64G, if your RAM is not bigger, then 4GiB.

If you have 64b CPU it is better for you to use 64b kernel and OS, so you would get 40-48b memory address (which greatly surpass 36b and 32b which is used by HighMem).

I considered to name all platforms, where microcode is easyly changeable.
Like SUNs or other Middleware.

But the question implied that it is running on a x86 architecture.

No. There are the same number of page table levels for "4GB" support (which really only gives you 3 and a fraction GB) as for 896MB support.

32bit with 896MB or 64bit (with any currently possible ram size) both allow permanent kernel mapping of all physical ram, which slightly reduces the complexity and execution time of some kernel operations. 32bit with any HighMem support (even to support a full 1GB) has a little extra overhead because of this.

PAE support adds one level of page table, which is a very trivial overhead. It allows access to physical ram up to 64GB, but data structures stop fitting in kernel virtual address space around 16GB. A kludge for kernel virtual addressing was available in some old versions of Red Hat to give practical support up to 64GB in 32bit, but that was inefficient and had many compatibility issues. I don't know if you can build that into a current kernel, but anyway you shouldn't.

If you have 4GB of ram, I think the difference between using very near 4GB vs. using only 3 and a small fraction is worth the trivial extra overhead of PAE.

If you have a 64bit CPU, it may be better to use a 64bit kernel.
Regardless of physical memory size, a 64bit kernel adds another level of page table beyond PAE (two levels beyond 32bit non PAE). So the slight overhead increase from non PAE to PAE in 32bit is doubled by 64bit. It avoids the slight overhead of the original highmem (the step from under 896MB to over). But all of those overhead changes are tiny. Other factors dominate the question of whether 64 bit is better.

If you have so much ram that kernel virtual space is exhausted and you need the kludge I mentioned above to stay in 32 bit, then certainly switch to 64 bit (if you had and needed that much ram with a 32bit CPU, it is past time to retire that expensive relic and replace it with something current). That limit is certainly hit if you have over 16GB and may be hit somewhat lower, depending on how the system is used.