64K page size
PATCH 1/1 64K page size
Hello,
There are a number of changes required to support larger page sizes, but this one I thought worth sending up right away.
The code in pgtable-64.h assumes TASK_SIZE is always bigger than a first level PGDIR_SIZE. This is not the case for 64K pages, where task size is 40 bits (1TB) and a pgd entry can map 42 bits. This leads to USER_PTRS_PER_PGD being zero for 64K pages.
If there is interest in other changes for 64K pages, I can send more.
include/asm-mips/pgtable-64.h +5 -1
@@ -93,8 +93,12 @@ #define PTRS_PER_PGD ((PAGE_SIZE << PGD_#define PTRS_PER_PMD ((PAGE_SIZE << PMD_ORDER) / sizeof(pmd_t))#define PTRS_PER_PTE ((PAGE_SIZE << PTE_ORDER) / sizeof(pte_t)) +#if PGDIR_SIZE >=TASK_SIZE +#define USER_PTRS_PER_PGD (1) +#else #define USER_PTRS_PER_PGD (TASK_SIZE / PGDIR_SIZE) -#define FIRST_USER_ADDRESS 0 +#endif +#define FIRST_USER_ADDRESS 0UL#define VMALLOC_START MAP_BASE#define VMALLOC_END \
Quoted 11 lines · Peter Watkins
Hello,
There are a number of changes required to support larger page sizes, but this one I thought worth sending up right away.
The code in
pgtable-64.hassumesTASK_SIZEis always bigger than a first levelPGDIR_SIZE. This is not the case for 64K pages, where task size is 40 bits (1TB) and a pgd entry can map 42 bits. This leads toUSER_PTRS_PER_PGDbeing zero for 64K pages.If there is interest in other changes for 64K pages, I can send more.
Please do so. :-)
Thiemo
I am extremely interested in big pages (64K, etc), and the sooner the better. If there is anything not considered OK for immediate inclusion in the Linux MIPS git tree, I would love to have a copy anyway. Large pages will be necessary for some high-priority work I'm doing, although stability at this point seems to be an optional extra. (Hence why the patches are much more important than whether they're actually finished yet.)
Jonathan
Quoted 15 lines · --- Thiemo Seufer
Quoted 3 lines · Peter Watkins
Hello,
There are a number of changes required to support
larger page sizes, but
Quoted 3 lines
this one I thought worth sending up right away.
The code in
pgtable-64.hassumesTASK_SIZEisalways bigger than a first
Quoted 1 line
level
PGDIR_SIZE. This is not the case for 64Kpages, where task size is
Quoted 1 line
40 bits (1TB) and a pgd entry can map 42 bits.
This leads to
Quoted 2 lines
USER_PTRS_PER_PGDbeing zero for 64K pages.
Quoted 9 lines
Quoted 1 line
If there is interest in other changes for 64K
pages, I can send more.
Please do so. :-)
Thiemo
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Quoted 9 lines · Jonathan Day
I am extremely interested in big pages (64K, etc), and the sooner the better. If there is anything not considered OK for immediate inclusion in the Linux MIPS git tree, I would love to have a copy anyway. Large pages will be necessary for some high-priority work I'm doing, although stability at this point seems to be an optional extra. (Hence why the patches are much more important than whether they're actually finished yet.)
Biggest drawback (besides stability concerns and some broken userspace programs) is the insane amount of memory it can take. Every tiny file would currently take 64k in the page cache. There's some work going on to collate such partially used pages into single ones, but that may take a while to become usable.
Thiemo
Quoted 9 lines · Jonathan Day
I am extremely interested in big pages (64K, etc), and the sooner the better. If there is anything not considered OK for immediate inclusion in the Linux MIPS git tree, I would love to have a copy anyway. Large pages will be necessary for some high-priority work I'm doing, although stability at this point seems to be an optional extra. (Hence why the patches are much more important than whether they're actually finished yet.)
64K pages are not the universal solution to world hunger. They're a tradeoff and usually one that is considered apropriate for full blown supercomputers. On smaller systems the memory overhead is likely to be prohibitive. The memory overhead problem is being worked on but it's likely to be quite some time before this is finished and integrated.
Do we want to get them to work? Of course, Linux/MIPS supports some extremly large systems. But aside of those 64K pagesize is rarely useful.
Ralf
The short answer is that I'm actually working on a MIPS-based supercomputer. :)
The longer answer is that the group I'm working with is linking an extremely large number of SB1-based MIPS nodes together to build a very large multicast-based cluster. Back-of-the-envelope calculations suggest that large pages - although inefficient on memory per node - would be highly efficient for what we have in mind.
(You are correct that this will not involve solving world hunger - although I'm always happy to be proven wrong on such matters.)
Large pages are not the only technical issue that has been bugging me - Linux clustering technology in general is a long way from where I'd like it to be - but I'm happy with the idea of someone solving one of the potentially larger thorns that has been bugging me for a while.
Jonathan Day
Quoted 11 lines · --- Ralf Baechle
64K pages are not the universal solution to world hunger. They're a
tradeoff and usually one that is considered apropriate for full blown
supercomputers. On smaller systems the memory overhead is likely to be
prohibitive. The memory overhead problem is being worked on but it's
likely to be quite some time before this is finished and integrated.
Quoted 7 lines
Do we want to get them to work? Of course,
Linux/MIPS supports some
extremly large systems. But aside of those 64K
pagesize is rarely useful.Ralf
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Quoted 9 lines · Jonathan Day
I am extremely interested in big pages (64K, etc), and the sooner the better. If there is anything not considered OK for immediate inclusion in the Linux MIPS git tree, I would love to have a copy anyway. Large pages will be necessary for some high-priority work I'm doing, although stability at this point seems to be an optional extra. (Hence why the patches are much more important than whether they're actually finished yet.)
We're getting very close to a 2.6.18 release and 64kB pages are still quite experimental, so I'm putting all the 64kB pagesize related fixes into the queue branch. 16kB by now has a few users, so I give it higher priority.
I've been promised hugetlbfs since quite a while but that somehow never materialized. Or maybe that's just because the runtime generated TLB exception handlers killed the patches ;-)
Ralf
Hi Ralf,
Quoted 12 lines · On Tue, 29 Aug 2006 15:07:00 +0100 Ralf Baechle <[email protected]> wrote:
Quoted 9 lines · Jonathan Day
I am extremely interested in big pages (64K, etc), and the sooner the better. If there is anything not considered OK for immediate inclusion in the Linux MIPS git tree, I would love to have a copy anyway. Large pages will be necessary for some high-priority work I'm doing, although stability at this point seems to be an optional extra. (Hence why the patches are much more important than whether they're actually finished yet.)
Quoted 4 lines
We're getting very close to a 2.6.18 release and 64kB pages are still quite experimental, so I'm putting all the 64kB pagesize related fixes into the queue branch. 16kB by now has a few users, so I give it higher priority.
Which is your queue branch?
I want to test 64k page size on vr41xx.
Yoichi
Quoted 7 lines · Yoichi Yuasa
Quoted 4 lines
We're getting very close to a 2.6.18 release and 64kB pages are still quite experimental, so I'm putting all the 64kB pagesize related fixes into the queue branch. 16kB by now has a few users, so I give it higher priority.
Which is your queue branch?
I want to test 64k page size on vr41xx.
It's just named "queue" in the usual git repository on linux-mips.org.
Ralf
Quoted 7 lines · Peter Watkins
There are a number of changes required to support larger page sizes, but this one I thought worth sending up right away.
The code in
pgtable-64.hassumesTASK_SIZEis always bigger than a first levelPGDIR_SIZE. This is not the case for 64K pages, where task size is 40 bits (1TB) and a pgd entry can map 42 bits. This leads toUSER_PTRS_PER_PGDbeing zero for 64K pages.
Do you actually need large address space? The kernel could allow 2, 3 and 4-level pagetables easily but doesn't give that choice currently.
Ralf
Quoted 5 lines · Ralf Baechle
Quoted 1 line
The code in
pgtable-64.hassumesTASK_SIZEis always bigger than a first levelPGDIR_SIZE. This is not the case for 64K pages, where task size is 40 bits (1TB) and a pgd entry can map 42 bits. This leads toUSER_PTRS_PER_PGDbeing zero for 64K pages.Do you actually need large address space? The kernel could allow 2, 3 and 4-level pagetables easily but doesn't give that choice currently.
Yes, in some cases. I'd like to benchmark the performance difference between 2 and 3 level pagetables, so the choice is valuable.
Ralf Baechle
AppliedQuoted 7 lines · Peter Watkins
There are a number of changes required to support larger page sizes, but this one I thought worth sending up right away.
The code in
pgtable-64.hassumesTASK_SIZEis always bigger than a first levelPGDIR_SIZE. This is not the case for 64K pages, where task size is 40 bits (1TB) and a pgd entry can map 42 bits. This leads toUSER_PTRS_PER_PGDbeing zero for 64K pages.
Thanks, applied.
Ralf