Hi,
I am working on a project that keep accessing lots of memory randomly(say
500MB-1.5GB) and we do have such amount of memory installed so there's
almost no page faults while running the entire program. Since x86
architecutre has a 4M page feature, is it possible to make use of these big
pages instead of 4K pages in my program (a user-level application) so I can
expect much fewer TLB misses due to the reduced number of TLB entries?
Thanks very much!
_________________________________________________________________
Join the world?s largest e-mail service with MSN Hotmail.
http://www.hotmail.com
On Thu, 17 Jan 2002, Yinlei Yu wrote:
> I am working on a project that keep accessing lots of memory
> randomly(say 500MB-1.5GB) and we do have such amount of memory
> installed so there's almost no page faults while running the entire
> program. Since x86 architecutre has a 4M page feature, is it possible
> to make use of these big pages instead of 4K pages in my program (a
> user-level application) so I can expect much fewer TLB misses due to
> the reduced number of TLB entries?
This isn't currently implemented, still somewhere on the TODO list ;/
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
I brought this to the list once about a half a year ago. One item I got
in feedback was that
it would require a reverse-mapping allocator (for the cases of mappings
to ram) to be able to coalesce/rearrange pages to
make room for contiguous 4M pages. Such an allocator now exists...
search an LKML archive for "rmap".
In the case of non-swappable memory, the allocator is not an issue. In
fact the kernel does use 4M pages to map the kernel itsself
(non-swappable and contiguous) and the 1:1 mapping of physical memory on
non-himem kernels.(not 100% sure about that part) I immagine this could
be easily extended to things like the bt848, the framebuffer on all
video cards (ok not ISA-VGA), and any mmio regions sufficiently large
enough. ( or redo BIOS PCI setup so regions are at least 4M apart...)
As for reduced TLB misses... I just read the specs for decoding the MSRs
on AMD processors to determine cache organization, and it turns out that
they have separate TLBs for 4k vs 4M pages. So you actually get more TLB
entries by using 4M pages...
Now I guess we need to start thinking about extent based filesystems and
how to page in/out 4M pages...mmap files...
Yinlei Yu wrote:
> Hi,
>
> I am working on a project that keep accessing lots of memory
> randomly(say 500MB-1.5GB) and we do have such amount of memory
> installed so there's almost no page faults while running the entire
> program. Since x86 architecutre has a 4M page feature, is it possible
> to make use of these big pages instead of 4K pages in my program (a
> user-level application) so I can expect much fewer TLB misses due to
> the reduced number of TLB entries? Thanks very much!
>
>
>
>
>
>
> _________________________________________________________________
> Join the world's largest e-mail service with MSN Hotmail.
> http://www.hotmail.com
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Hi Yinlei :)
>Since x86 architecutre has a 4M page feature
I may certainly be wrong but... is not 4k OR 16M the page size on
x86 arch? I didn't know about 4M page. Could you send me the GTD
settings for that? (Just curiosity :)))
Ra?l
DervishD wrote:
>
> Hi Yinlei :)
>
> >Since x86 architecutre has a 4M page feature
>
> I may certainly be wrong but... is not 4k OR 16M the page size on
> x86 arch? I didn't know about 4M page. Could you send me the GTD
> settings for that? (Just curiosity :)))
The large page size is 4MB, except in PAE mode where they are 2MB.
Normal pages are always 4KB. Noting in the GDT affects the page size.
--
Brian Gerst
Hi Brian :)
>The large page size is 4MB, except in PAE mode where they are 2MB.
>Normal pages are always 4KB. Noting in the GDT affects the page
>size.
The entries in the GDT, do not set the page size for that
descriptor? I'm certainly rusted on the i386 O:)))
Ra?l
DervishD wrote:
>
> Hi Brian :)
>
> >The large page size is 4MB, except in PAE mode where they are 2MB.
> >Normal pages are always 4KB. Noting in the GDT affects the page
> >size.
>
> The entries in the GDT, do not set the page size for that
> descriptor? I'm certainly rusted on the i386 O:)))
>
> Ra?l
No, there is a bit in the page directory that determines if the entry
points to a page table (with 4KB pages) or to a 4MB page. The GDT is
only used for segmentation, which is totally seperate from paging.
--
Brian Gerst
On Fri, 18 Jan 2002, DervishD wrote:
> Hi Brian :)
>
> >The large page size is 4MB, except in PAE mode where they are 2MB.
> >Normal pages are always 4KB. Noting in the GDT affects the page
> >size.
>
> The entries in the GDT, do not set the page size for that
> descriptor? I'm certainly rusted on the i386 O:)))
>
> Ra?l
Nope! You might be confusing the "granularity" number. This just
tells the CPU how to interpret the rest of the stuff. Right now
the base and limit is set for 32-bits for a, gawd help me,
`segment`. You can go back to 16-bit segments if you want.
Paging is different, there's a single bit that controls the size
of a page; small or big, nothing in-between. That's it.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
Hello Brian :)
>> The entries in the GDT, do not set the page size for that
>> descriptor? I'm certainly rusted on the i386 O:)))
>No, there is a bit in the page directory that determines if the entry
>points to a page table (with 4KB pages) or to a 4MB page. The GDT is
>only used for segmentation, which is totally seperate from paging.
That was my confusion: I forgot that the i386 does segmentation
AND paging. Thanks for the help :) I've taking a look at a book that
I had gathering dust (maybe 8 years...), by Douglas V.Hall. I must
take a really *deep* read into it and other i386 documentation before
getting in this kind of conversations O:)). Thanks again for your help.
Ra?l