[lkml]   [2000]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: 2.4 MM overview?
> > We've kind of got 1.5-level page tables.  There are actually 3
> page tables.
> > The system page table maps memory starting at 0x80000000. The
> P0 process
> > page table maps from 0x0 up and the P1 process page table maps from
> > 0x7fffffff down.
> And they have to be physically contiguous I guess ?

The system page table must be physically contiguous. The process tables
are actually referred to via virtual addresses, so they only have to
be virtually contiguous in system space.

> > This means that sparse address spaces are going to be _really_ expensive
> > on PTEs. I don't know how much of a problem this is going to be yet,
> > but I'm sure it's going to be fun :-)
> 512 byte pages, 4 bytes per pte ? Ouch. Can you fill the TLB manually ?

That's not the worst! Considering the 4-byte PTE and the 40-byte mem_map_t,
our memory management overhead is at least 44 bytes/page or 8.5%!

We are formulating cunning plans of aggregating 2, 4 or 8 pages together
into "bigpages", telling the arch-independent code that we've got
larger pages than we really have and manipulating multiple PTEs in the
set_pte() primitive and friends.

We don't know how feasible this is yet..

> OTOH, I think mapping all physical memory makes sense with the three page
> table setup.

It might and it might not. Expanding the system page table is pretty
much out of the question because it needs to be physically contiguous.
So we need to allocate system PTEs for the following at boot time:

1. Map all physical memory pages
2. Spare PTEs for mapping I/O space via ioremap().
3. Spare PTEs for vmalloc()

It seems a bit wasteful that process pages will have two PTEs, one in
the relevant process page table and one in the system page table.
If we could get away without needing the system PTE, then this would
either provide more space for #2 and #3 above, or reduce the size
of the system page table.

How much space tends to be vmalloc()-ed in a running system?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:41    [W:0.059 / U:26.652 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site