lkml.org 
[lkml]   [2000]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: 2.4 MM overview?
Date
> > 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%!
>
> use a logical page size of 4kb.
>
> > 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..
>
> why wouldn't it be feasible ?

Because I don't know this part of the kernel well enough yet :-)
Maybe there are cuncurrency issues with modifying multiple PTEs
when the kernel thinks it's only modifying one. There may be
hardware-mandated limitations on this too. I'll have to check
_very_ closely with the VAX Architecture Reference Manual.

> > > 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.
>
> agreed.
>
> > 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()
> 4. Spare PTEs for making user process page tables virtually
> contiguous.

Couldn't we use vmalloc() for this?

> Note
> that this effectively gives you a two-level page table.
> (Actually, a 3-level
> page table, with 2 pmds per pgd, 4K PTEs per 3rd-level page table, and 512
> bytes per page.)
>
> So, here's what I'm proposing:

I'll need to examine this more closely when I get home later.
Too busy right now :-(

> > 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.
>
> why ? You lose 0.78 % of your physical memory compared to the more
> complicated design, which shouldn't hurt too much.

The 'scarce resource' I'm thinking about here is not memory, it's
system PTEs.

> It might make sense
> if you have tons of physical memory though so you can use all of it
> (where tons I'd guess to be about 1.8 GB, not knowing too much about
> the architecture).

Memory from 0xc0000000 to 0xffffffff is not usable in VAX, so
map-all-memory will give a maximum of just under 1GB. I have
a feeling that there is an architectural limit of 1GB anyway
(21-bit page frame number + 9 bit PAGE_SHIFT = 30 bits = 1GB).

> > How much space tends to be vmalloc()-ed in a running system?
>
> See the discussion for alpha a week or so ago. It tends to not
> be very much
> but for some applications (TUX, for example), it's expected to be most of
> physical memory.

Dammit! Must have been just before I subscribed... I'll do
some archive archeology later.

Later,
Kenn

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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