> > 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/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:09 EST