Messages in this thread | | | From | "Kenn Humborg" <> | Subject | RE: 2.4 MM overview? | Date | Mon, 16 Oct 2000 14:11:58 +0100 |
| |
> > 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/
| |