On Sun, Oct 15, 2000 at 11:35:23PM +0100, Kenn Humborg wrote:
> We've kind of got 1.5-level page tables. There are actually 3 page tables.
> The system page table maps memory starting at 0x8000. The P0 process
> page table maps from 0x0 up and the P1 process page table maps from
> 0x7ff
> 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.
If you ever want to get the networking behavin
> > 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 t
On Mon, Oct 16, 2000 at 12:54:33PM +0100, Kenn Humborg wrote:
> > > We've kind of got 1.5-level page tables. There are actually 3
> > page tables.
> > > The system page table maps memory starting at 0x8000. The
> > P0 process
> > > page table maps from 0x0 up and the P1 process page table ma
> > We've kind of got 1.5-level page tables. There are actually 3
> page tables.
> > The system page table maps memory starting at 0x8000. The
> P0 process
> > page table maps from 0x0 up and the P1 process page table maps from
> > 0x7fff down.
>
> And they have to be physically contiguo
On Sun, Oct 15, 2000 at 11:35:23PM +0100, Kenn Humborg wrote:
> On Sun, Oct 15, 2000 at 09:45:11PM +0100, Alan Cox wrote:
> > > Well, we ain't got these luxuries/complications in VAXland... Hell,
> > > we don't even have two-level page tables :-(
> >
> > Really. Ugh. I always assumed Vax had at
On Sun, Oct 15, 2000 at 09:45:11PM +0100, Alan Cox wrote:
> > Well, we ain't got these luxuries/complications in VAXland... Hell,
> > we don't even have two-level page tables :-(
>
> Really. Ugh. I always assumed Vax had at least two levels because mmap on
> 4.2 BSD used to panic on 128K+ block
> You mean like the way the Alpha has a PTE bit that says 'this page is
> valid at the same address in every process', and the address space
> number (ASN) that can be used to 'uniquefy' cache entries for the
> same virtual addresses in different processes?
Exactly
> Well, we ain't got these lux
On Sun, Oct 15, 2000 at 09:22:58PM +0100, Alan Cox wrote:
> > > or you have a sane memory management model with tags/spaces then its a non issue
> >
> > You've lost me here. Tags/spaces?
>
> A lot of memory management hardware allows you to build page tables that contain
> more than just the ad
> > or you have a sane memory management model with tags/spaces then its a non issue
>
> You've lost me here. Tags/spaces?
A lot of memory management hardware allows you to build page tables that contain
more than just the addresses. Instead a tag register or the processor state
or both are com
On Sun, Oct 15, 2000 at 08:35:46PM +0100, Alan Cox wrote:
> > I understand that 2.4 no longer maps all physical memory as 2.2
> > and earlier used to do.
>
> Its really up to you if you choose to do that or not. If you have enough
> address space to create all your virtual and physical mappings
> I understand that 2.4 no longer maps all physical memory as 2.2
> and earlier used to do.
Its really up to you if you choose to do that or not. If you have enough
address space to create all your virtual and physical mappings without problems,
or you have a sane memory management model with ta
On Sun, Oct 15, 2000 at 08:07:06PM +0200, Andi Kleen wrote:
> On Sun, Oct 15, 2000 at 05:29:46PM +0100, Kenn Humborg wrote:
> >
> >
> > __pa() and __va() are still defined as addr -/+ PAGE_OFFSET. So
> > where did I hear about 2.4 not mapping all memory? Could it be
> > that this applies only
Andi Kleen writes:
> On Sun, Oct 15, 2000 at 05:29:46PM +0100, Kenn Humborg wrote:
> >
> >
> > __pa() and __va() are still defined as addr -/+ PAGE_OFFSET. So
> > where did I hear about 2.4 not mapping all memory? Could it be
> > that this applies only to "high memory" in x86?
>
> It only app
On Sun, Oct 15, 2000 at 05:29:46PM +0100, Kenn Humborg wrote:
>
>
> __pa() and __va() are still defined as addr -/+ PAGE_OFFSET. So
> where did I hear about 2.4 not mapping all memory? Could it be
> that this applies only to "high memory" in x86?
It only applies to high memory. To access it y
On Sun, Oct 15, 2000 at 06:03:40PM +0200, Erik Mouw wrote:
> On Sun, Oct 15, 2000 at 04:24:45PM +0100, Kenn Humborg wrote:
> > I understand that 2.4 no longer maps all physical memory as 2.2
> > and earlier used to do.
> >
> > Is there any documentation on this change and how it affects
> > arch-
On Sun, Oct 15, 2000 at 04:24:45PM +0100, Kenn Humborg wrote:
> I understand that 2.4 no longer maps all physical memory as 2.2
> and earlier used to do.
>
> Is there any documentation on this change and how it affects
> arch-specific code?
>
> Specifically, we've been basing the VAX port on 2.2
I understand that 2.4 no longer maps all physical memory as 2.2
and earlier used to do.
Is there any documentation on this change and how it affects
arch-specific code?
Specifically, we've been basing the VAX port on 2.2 while waiting
for 2.4 to stabilize. Now we're looking at moving to 2.4.
18 matches
Mail list logo
