Highmem - Revision history

Vomlehn: /* Problems */

2008-04-04T23:35:29Z

‎Problems

Ralf: /* Problems */

2008-02-14T12:22:24Z

‎Problems

Vomlehn: /* Problems */

2008-02-14T00:11:44Z

‎Problems

Vomlehn: /* Problems */

2007-12-14T22:15:17Z

‎Problems

Vomlehn: /* Problems */

2007-12-14T22:14:25Z

‎Problems

Ralf: Fix link to "Page size" page.

2006-08-29T13:54:00Z

Fix link to "Page size" page.

Ralf at 12:28, 5 November 2004

2004-11-05T12:28:56Z

Ralf at 12:26, 5 November 2004

2004-11-05T12:26:48Z

Ralf: /* Problems */

2004-11-05T09:51:30Z

‎Problems

Ralf at 09:48, 5 November 2004

2004-11-05T09:48:04Z

@@ Line 10: / Line 10: @@
 Highmem is accessed through temporary mappings.  Creation and teardown of such mappings are are not for free and mappings are only permitted to exist for a short time.  This means any kernel software using highmem needs to be written with special care or performance and stability of the entire system are at stake.
-Certain systems where memory may be outside the low 4GB physical address space will need to enable support for 64-bit physical addresses in pagetables also.  This will nearly double the size of pagetables.  Again pagetables resize in lowmem; this can be a large consumer of lowmem for system that make heavy use of mmap.
+Certain systems where memory may be outside the low 4GB physical address space will need to enable support for 64-bit physical addresses in pagetables also.  This will nearly double the size of pagetables.  Again pagetables reside in lowmem; this can be a large consumer of lowmem for system that make heavy use of mmap.
 While creation and teardown of mappings already are a significant overhead, the cacheflushes necessary to deal with [[cache aliases]] would dwarf that.  Therefore Linux/MIPS supports highmem only on systems that don't suffer from cache aliases.  A highmem kernel will boot on such a system but only use the lowmem.

@@ Line 6: / Line 6: @@
 == Problems ==
-Linux allocates a large array named mem_map[] in lowmem.  On 32-bit kernels it contains one 32-byte (i.e. sizeof (struct page)) entry per [[Page_size|page]] of memory.  Entries are allocated even for reserved memory ranges.  This consumption of lowmem means memory pressure on lowmem will rise with the amount of highmem.  In practice at most a ratio of 1:4 to 1:8 has been found to perform well.
+Linux allocates a large array named mem_map[] in lowmem.  On 32-bit kernels it contains one 32-byte (i.e. sizeof (struct page)) entry per [[Page_size|page]] of memory.  On Linux&nbsp;2.4 struct page used to be ''twice'' as large.  are allocated even for reserved memory ranges.  This consumption of lowmem means memory pressure on lowmem will rise with the amount of highmem.  In practice at most a ratio of 1:4 to 1:8 has been found to perform well.
 Highmem is accessed through temporary mappings.  Creation and teardown of such mappings are are not for free and mappings are only permitted to exist for a short time.  This means any kernel software using highmem needs to be written with special care or performance and stability of the entire system are at stake.

@@ Line 6: / Line 6: @@
 == Problems ==
-Linux allocates a large array named mem_map[] in lowmem.  On 32-bit kernels it contains one 64-byte entry per [[Page_size|page]] of memory.  Entries are allocated even for reserved memory ranges.  This consumption of lowmem means memory pressure on lowmem will rise with the amount of highmem.  In practice at most a ratio of 1:4 to 1:8 has been found to perform well.
+Linux allocates a large array named mem_map[] in lowmem.  On 32-bit kernels it contains one 32-byte (i.e. sizeof (struct page)) entry per [[Page_size|page]] of memory.  Entries are allocated even for reserved memory ranges.  This consumption of lowmem means memory pressure on lowmem will rise with the amount of highmem.  In practice at most a ratio of 1:4 to 1:8 has been found to perform well.
 Highmem is accessed through temporary mappings.  Creation and teardown of such mappings are are not for free and mappings are only permitted to exist for a short time.  This means any kernel software using highmem needs to be written with special care or performance and stability of the entire system are at stake.

@@ Line 12: / Line 12: @@
 Certain systems where memory may be outside the low 4GB physical address space will need to enable support for 64-bit physical addresses in pagetables also.  This will nearly double the size of pagetables.  Again pagetables resize in lowmem; this can be a large consumer of lowmem for system that make heavy use of mmap.
-While creation and teardown of mappings already are a significant overhead the cacheflushes necessary to deal with [[cache aliases]] would dwarf that.  Therefore Linux/MIPS supports highmem only on systems that don't suffer from cache aliases.  A highmem kernel will boot on such a system but only use the lowmem.
+While creation and teardown of mappings already are a significant overhead, the cacheflushes necessary to deal with [[cache aliases]] would dwarf that.  Therefore Linux/MIPS supports highmem only on systems that don't suffer from cache aliases.  A highmem kernel will boot on such a system but only use the lowmem.
 == Alternatives ==

@@ Line 10: / Line 10: @@
 Highmem is accessed through temporary mappings.  Creation and teardown of such mappings are are not for free and mappings are only permitted to exist for a short time.  This means any kernel software using highmem needs to be written with special care or performance and stability of the entire system are at stake.
-Certain systems where memory may be outside the low 4GB physical address space will need to enable support for 64-bit physical addresses in pagetables also.  This will nearly double the size of pagetables.  Again pagetables resize in lowmem; the can be a large consumer of lowmem for system that make heavy use of mmap.
+Certain systems where memory may be outside the low 4GB physical address space will need to enable support for 64-bit physical addresses in pagetables also.  This will nearly double the size of pagetables.  Again pagetables resize in lowmem; this can be a large consumer of lowmem for system that make heavy use of mmap.
 While creation and teardown of mappings already are a significant overhead the cacheflushes necessary to deal with [[cache aliases]] would dwarf that.  Therefore Linux/MIPS supports highmem only on systems that don't suffer from cache aliases.  A highmem kernel will boot on such a system but only use the lowmem.

← Older revision		Revision as of 12:28, 5 November 2004
Line 16:		Line 16:
	== Alternatives ==		== Alternatives ==
	64-bit kernels use XKPHYS to access their lowmem. Due to the size of XKPHYS the entire physical memory is directly accessible so highmem isn't needed with 64-bit kernels. 64-bit kernels have somewhat larger code and data resulting in a slight slowdown. This however is by far preferable over the impact of highmem.		64-bit kernels use XKPHYS to access their lowmem. Due to the size of XKPHYS the entire physical memory is directly accessible so highmem isn't needed with 64-bit kernels. 64-bit kernels have somewhat larger code and data resulting in a slight slowdown. This however is by far preferable over the impact of highmem.
		+
		+	== See Also ==
		+	[[Jaguar ATX]] for some creative abuse of the kernel's highmem facilities.

← Older revision		Revision as of 09:48, 5 November 2004
Line 4:		Line 4:
	== Memory Managment on Linux/MIPS ==		== Memory Managment on Linux/MIPS ==
	32-bit Linux/MIPS kernels assume the entire low memory to be accessible through KSEG0 which limits lowmem to at most 512MB. Typical MIPS systems reserve part of that address space for other uses so a lowmem limit of 256MB is a common value. Memory beyond that can be used by 64-bit kernels or 32-bit kernels with highmem support enabled.		32-bit Linux/MIPS kernels assume the entire low memory to be accessible through KSEG0 which limits lowmem to at most 512MB. Typical MIPS systems reserve part of that address space for other uses so a lowmem limit of 256MB is a common value. Memory beyond that can be used by 64-bit kernels or 32-bit kernels with highmem support enabled.
		+
		+	== Problems ==
		+	Linux allocates a large array named mem_map[] in lowmem. On 32-bit kernels it contains one 64-byte entry per [[pagesize\|page]] of memory. Entries are allocated even for reserved memory ranges. This consumption of lowmem means memory pressure on lowmem will rise with the amount of highmem. In practice at most a ratio of 1:4 to 1:8 has been found to perform well.
		+
		+	Highmem is accessed through temporary mappings. Creation and teardown of such mappings are are not for free and mappings are only permitted to exist for a short time. This means any kernel software using highmem needs to be written with special care or performance and stability of the entire system are at stake.
		+
		+	== Alternatives ==
		+	64-bit kernels use XKPHYS to access their lowmem. Due to the size of XKPHYS the entire physical memory is directly accessible so highmem isn't needed with 64-bit kernels. 64-bit kernels have somewhat larger code and data resulting in a slight slowdown. This however is by far preferable over the impact of highmem.