Searched hist:"4 a56c1e4" (Results 1 – 2 of 2) sorted by relevance
/openbmc/linux/arch/arm/mm/ |
H A D | ioremap.c | 4a56c1e4 Sat Apr 21 04:16:48 CDT 2007 Russell King <rmk@dyn-67.arm.linux.org.uk> [ARM] mm 3: separate out supersection mappings, avoid for <4GB
Catalin Marinas at ARM Ltd says: > The CPU architects in ARM intended supersections only as a way to map > addresses >= 4GB. Supersections are not mandated by the architecture > and there is no easy way to detect their hardware support at run-time > (other than checking for a specific core). From the analysis done in > ARM, there wasn't a clear performance gain by using supersections > rather than sections (no significant improvement in the TLB misses).
Therefore, we should avoid using supersections unless there's a real need (iow, we're mapping addresses >= 4GB).
This means that we can simplify create_mapping() a bit since we will only use supersection mappings for addresses >= 4GB, which means that the physical, virtual and length must be multiples of the supersection mapping size.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 4a56c1e4 Sat Apr 21 04:16:48 CDT 2007 Russell King <rmk@dyn-67.arm.linux.org.uk> [ARM] mm 3: separate out supersection mappings, avoid for <4GB Catalin Marinas at ARM Ltd says: > The CPU architects in ARM intended supersections only as a way to map > addresses >= 4GB. Supersections are not mandated by the architecture > and there is no easy way to detect their hardware support at run-time > (other than checking for a specific core). From the analysis done in > ARM, there wasn't a clear performance gain by using supersections > rather than sections (no significant improvement in the TLB misses). Therefore, we should avoid using supersections unless there's a real need (iow, we're mapping addresses >= 4GB). This means that we can simplify create_mapping() a bit since we will only use supersection mappings for addresses >= 4GB, which means that the physical, virtual and length must be multiples of the supersection mapping size. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
H A D | mmu.c | 4a56c1e4 Sat Apr 21 04:16:48 CDT 2007 Russell King <rmk@dyn-67.arm.linux.org.uk> [ARM] mm 3: separate out supersection mappings, avoid for <4GB
Catalin Marinas at ARM Ltd says: > The CPU architects in ARM intended supersections only as a way to map > addresses >= 4GB. Supersections are not mandated by the architecture > and there is no easy way to detect their hardware support at run-time > (other than checking for a specific core). From the analysis done in > ARM, there wasn't a clear performance gain by using supersections > rather than sections (no significant improvement in the TLB misses).
Therefore, we should avoid using supersections unless there's a real need (iow, we're mapping addresses >= 4GB).
This means that we can simplify create_mapping() a bit since we will only use supersection mappings for addresses >= 4GB, which means that the physical, virtual and length must be multiples of the supersection mapping size.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 4a56c1e4 Sat Apr 21 04:16:48 CDT 2007 Russell King <rmk@dyn-67.arm.linux.org.uk> [ARM] mm 3: separate out supersection mappings, avoid for <4GB Catalin Marinas at ARM Ltd says: > The CPU architects in ARM intended supersections only as a way to map > addresses >= 4GB. Supersections are not mandated by the architecture > and there is no easy way to detect their hardware support at run-time > (other than checking for a specific core). From the analysis done in > ARM, there wasn't a clear performance gain by using supersections > rather than sections (no significant improvement in the TLB misses). Therefore, we should avoid using supersections unless there's a real need (iow, we're mapping addresses >= 4GB). This means that we can simplify create_mapping() a bit since we will only use supersection mappings for addresses >= 4GB, which means that the physical, virtual and length must be multiples of the supersection mapping size. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|