pte-highmem vs UKVA (was: object-based rmap and pte-highmem)

pte-highmem vs UKVA (was: object-based rmap and pte-highmem)

Post by Martin J. Blig » Tue, 25 Feb 2003 00:10:13



Quote:>> > The thing is, you _cannot_ have a per-thread area, since all threads
>> > share the same TLB.  And if it isn't per-thread, you still need all the
>> > locking and all the scalability stuff that the _current_ pte_highmem
>> > code needs, since there are people with thousands of threads in the
>> > same process.

>> I don't see why that's an issue - the pagetables are per-process, not
>> per-thread.

> Exactly. Which means that UKVA has all the same problems as the current
> global map.

> There are _NO_ differences. Any problems you have with the current global
> map you would have with UKVA in threads. So I don't see what you expect
> to  win from UKVA.

This just just for PTEs ... for which at the moment we have two choices:
1. Stick them in lowmem (fills up the global space too much).
2. Stick them in highmem - too much overhead doing k(un)map_atomic
   as measured by both myself and Andrew.

Using UKVA for PTEs seems to be a better way to implement pte-highmem to me.
If you're walking another processes' pagetables, you just kmap them as now,
but I think this will avoid most of the kmap'ing (if we have space for two
sets of pagetables so we can do a little bit of trickery at fork time).

Quote:>> Yes, that was a stalling point for sticking kmap in there, which was
>> amongst my original plotting for it, but the stuff that's per-process
>> still works.

> Exactly what _is_ "per-process"? The only thing that is per-process is
> stuff that is totally local to the VM, by the linux definition.

The pagetables.

Quote:> And the rmap stuff certainly isn't "local to the VM". Yes, it is torn
> down  and built up by the VM, but it needs to be traversed by global code.

Sorry, subject was probably misleading ... I'm just talking about the
PTEs here, not sticking anything to do with rmap into UKVA.

Partially object-based rmap is cool for other reasons, that have little to
do with this. ;-)

M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

pte-highmem vs UKVA (was: object-based rmap and pte-highmem)

Post by William Lee Irwin II » Tue, 25 Feb 2003 00:20:07



> Using UKVA for PTEs seems to be a better way to implement pte-highmem to me.
> If you're walking another processes' pagetables, you just kmap them as now,
> but I think this will avoid most of the kmap'ing (if we have space for two
> sets of pagetables so we can do a little bit of trickery at fork time).

Another term for "UKVA for pagetables only" is "recursive pagetables",
if this helps clarify anything.

-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

pte-highmem vs UKVA (was: object-based rmap and pte-highmem)

Post by Linus Torvald » Tue, 25 Feb 2003 02:40:09



Quote:

> Another term for "UKVA for pagetables only" is "recursive pagetables",
> if this helps clarify anything.

Oh, ok. We did that for alpha, and it was a good deal there (it's actually
architected for alpha). So yes, I don't mind doing it for the page tables,
and it should work fine on x86 too (it's not necessarily a very portable
approach, since it requires that the pmd- and the pte- tables look the
same, which is not always true).

So sure, go ahead with that part.

                Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

pte-highmem vs UKVA (was: object-based rmap and pte-highmem)

Post by Martin J. Blig » Tue, 25 Feb 2003 05:10:08


Quote:> This just just for PTEs ... for which at the moment we have two choices:
> 1. Stick them in lowmem (fills up the global space too much).
> 2. Stick them in highmem - too much overhead doing k(un)map_atomic
>    as measured by both myself and Andrew.

Actually Andrew's measurements seem to be a bit different from mine ...
several different things all interacting. I'll try to get some more
measurements from a straight SMP box, and see if they correlate more
closely with what he's seeing.

M.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. object-based rmap and pte-highmem

I have a plan for that (UKVA) ... we reserve a per-process area with
kernel type protections (either at the top of user space, changing
permissions appropriately, or inside kernel space, changing per-process
vs global appropriately).

This area is permanently mapped into each process, so that there's no
kmap_atomic / tlb_flush_one overhead ... it's highmem backed still.
In order to do fork efficiently, we may need space for 2 sets of
pagetables (12Mb on PAE).

Dave McCracken had an earlier implementation of that, but we never saw
an improvement (quite possibly because the fork double-space wasn't
there) - Dave Hansen is now trying to get something work with current
kernels ... will let you know.

M.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. general protection:0000 - what does this mean?????

3. pte-highmem-5

4. Solaris Exams

5. alpha update for pte highmem stuff in 2.5.5

6. UMAX S900 IMS Twin Turbo 4MB

7. kernel panic with pte-highmem-5

8. xfilemanage dies with 'Error: Cannot find Icon (null)'

9. Performance of partial object-based rmap

10. Optimizaction for object-based rmap

11. Performance of partial object-based rmap

12. alpha pte/pmd alloc update vs. 2.4.3

13. alpha: pte/pfn/page/tlb macros update [1/10]