tools to convert debian sarge to 16K page size
hi,
Some time ago I promised this:
Attached is some program/scripts to convert sarge debs to 16k page
compatible,that is, a kernel with PAGE_SIZE == 16K can use it.
There is a simple README in the tar file.
Quoted 7 lines · Fuxin Zhang
hi,
Some time ago I promised this:Attached is some program/scripts to convert sarge debs to 16k page
compatible,that is, a kernel withPAGE_SIZE== 16K can use it.There is a simple README in the tar file.
Can you provide information about the performance impact? That is, what system(s) you use, and some basic benchmark numbers. Did you also try 64k pages?
Thiemo
Quoted 3 lines · Thiemo Seufer
Can you provide information about the performance impact? That is, what system(s) you use, and some basic benchmark numbers. Did you also try 64k pages?
The system is running debian sarge,with a mips like Chinese 4-way superscalar CPU and marvell 64240 system bridge, 256M sdram.Maybe related information: this CPU has 64K 4-way dcache/icache，so cache alias exists with 4K configuration.
Big page size helps a bit with at least computational programs, such as SPEC CPU2000 benchmarks. The attached jpg is a graph showing the results of some SPEC programs under different page sizes. But we have not benchmarked other workloads. 16K page size is used mainly to avoid cache alias, which caused us too much time.
Yes, with 64k more patches needed(some "short" field overflow?I don't remember the exact modifications,other guys did it)
Quoted 6 lines
Thiemo
Quoted 9 lines · Fuxin Zhang
Quoted 3 lines · Thiemo Seufer
Can you provide information about the performance impact? That is, what system(s) you use, and some basic benchmark numbers. Did you also try 64k pages?
The system is running debian sarge,with a mips like Chinese 4-way superscalar CPU and marvell 64240 system bridge, 256M sdram.Maybe related information: this CPU has 64K 4-way dcache/icache，so cache alias exists with 4K configuration.
Quoted 8 lines
Big page size helps a bit with at least computational programs, such as SPEC CPU2000 benchmarks. The attached jpg is a graph showing the results of some SPEC programs under different page sizes. But we have not benchmarked other workloads. 16K page size is used mainly to avoid cache alias, which caused us too much time.
Yes, with 64k more patches
needed(some "short" field overflow?I don't remember the exact modifications,other guys did it)
There is more to large pages than just improved performance. They'll also save 75% memory for mem_map, will eleminate cache aliases in a bulletproof way. And will make allocation of memory larger than 4kB reliable - this especially is a big bonus with ethernet jumboframes with some NICs.
Ralf