Why *not* rmap, anyway?

Why *not* rmap, anyway?

[Joseph A Knapka]

Hi folks,

I was just reading Bill's reply regaring rmap, and it
seems to me that rmap is the most obvious and clean
way to handle unmapping pages. So now I wonder why
it wasn't done that way from the beginning?

It took me a while to figure out all the complicated
interactions between virtual and physical scanning
in the Linux mm system. If I were writing a VM system
and I got to the point where I wanted to be able to
unmap a possibly-shared page, I would say to myself,
"Hmm, this will require a map of physical pages
to all their virtual addresses. Ick. But on the
other hand, the alternatives are probably a lot more
complicated," and I would just go ahead and implement
physical-to-virtual mappings. So why did Linus and/or
the MM hackers of ages past implement the parallel
virtual-and-physical-scanning thing? What are the
advantages, besides less data overhead? It seems
to me that the old method really complicates the
code a lot, and gives the CPU more work to do to
boot.

Thanks,

-- Joe
  Using open-source software: free.
  Pissing Bill Gates off: priceless.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Martin J. Bligh]

> I was just reading Bill's reply regaring rmap, and it
> seems to me that rmap is the most obvious and clean
> way to handle unmapping pages. So now I wonder why
> it wasn't done that way from the beginning?

Because it costs something to maintain the reverse map.
If the cost exceeds the benefit, it's not worth it. That's
why a bunch of us are working on bringing the cost down.
At the moment the cost is especially high on larger machines,
but we're getting there ... quickly ;-)

Martin.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Joseph A Knapka]

"Martin J. Bligh" wrote:
> 
> > I was just reading Bill's reply regaring rmap, and it
> > seems to me that rmap is the most obvious and clean
> > way to handle unmapping pages. So now I wonder why
> > it wasn't done that way from the beginning?
> 
> Because it costs something to maintain the reverse map.
> If the cost exceeds the benefit, it's not worth it. That's

Sure, but it's not obvious (is it?) that the rmap cost
exceeds the cost of scanning every process's virtual
address space looking for pages to unmap.

I'll have to look at the rmap patch and see. And
I gather that the *BSDs have always had reverse-
mappings, but thus far I haven't been able to
fathom the BSD code tree well enough to track down
on the VM code.

Thanks,

-- Joe
  Using open-source software: free.
  Pissing Bill Gates off: priceless.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Martin J. Bligh]

>> Because it costs something to maintain the reverse map.
>> If the cost exceeds the benefit, it's not worth it. That's
> 
> Sure, but it's not obvious (is it?) that the rmap cost
> exceeds the cost of scanning every process's virtual
> address space looking for pages to unmap.

No, but neither is it obvious that the cost of the virtual
scanning exceeds the cost of rmap ;-)

I think rmap will win in the end, but there's really only 
one way to prove it ;-)

M.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Christian Smith]

On Sun, 21 Apr 2002, Joseph A Knapka wrote:

>"Martin J. Bligh" wrote:
>> 
>> > I was just reading Bill's reply regaring rmap, and it
>> > seems to me that rmap is the most obvious and clean
>> > way to handle unmapping pages. So now I wonder why
>> > it wasn't done that way from the beginning?
>> 
>> Because it costs something to maintain the reverse map.
>> If the cost exceeds the benefit, it's not worth it. That's
>
>Sure, but it's not obvious (is it?) that the rmap cost
>exceeds the cost of scanning every process's virtual
>address space looking for pages to unmap.

Just to stoke the flames somewhat, but I think the empirical evidence 
of any of the BSDs versus Linux on identical harware seems to suggest that 
reverse mapping provides a big win.

Also, the reverse mapping provides *SIMPLER* page accounting, which can 
greatly improve the chances of paging out a suitable page in low memory 
conditions, and can be a substantial win if more correct pages are paged 
out. Even if the process of scanning takes longer (which is debatable,) 
scanning is so much quicker than physical disk transfer that it must be 
preferable.

Finally, the cost of scanning the non-rmap pages becomes proportional to
the amount of VM in use, which I presume is O(n). As the number of pages
in a machine (without hotplug memory!) remains constant , the scan time is
mostly constant[1], no matter how much VM is in use. As the greatest need 
for efficient scanning is when there is lots of VM in use (and hence 
memory,) non-rmap does it's worse precisely when it is required to perform 
it's best!

[1] Under extreme memory circumstances, multiple scans may be required, 
but that is true of non-rmap as well.

>
>I'll have to look at the rmap patch and see. And
>I gather that the *BSDs have always had reverse-
>mappings, but thus far I haven't been able to
>fathom the BSD code tree well enough to track down
>on the VM code.

NetBSD and OpenBSD are UVM based. FreeBSD uses a modified Mach based VM 
from 4.4BSD. In both cases, the layer is processor independant.

All three use the Mach pmap interface for machine dependant MMU interface. 
It basically provides an opaque MMU API.

On NetBSD (and probably OpenBSD,) the UVM layer is in /usr/src/sys/uvm. 
The FreeBSD VM is probably in /usr/src/sys/vm, but I've only got a NetBSD 
machine here to check.

The pmap layer is in /usr/src/sys/arch/<processor>/<processor>, interface 
in /usr/src/sys/arch/<processor>/include/pmap.h.

>
>Thanks,
>

The question becomes, how much work would it be to rip out the Linux MM 
piece-meal, and replace it with an implementation of UVM? It would 
probably require modifications not only to memory related functions, but 
also the VFS. It would certainly be a bigger job than the AA MM swap, as 
AA was a plug in replacement for the old VM, whereas UVM may not fit so 
nicely.

Has anyone looked at this? Is it doable? IMO, Linux MM sucks rocks, and is 
light years behind BSD and SysV. Even NT has rmap!

Christian

-- 
    /"\
    \ /    ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL 
     X                           - AGAINST MS ATTACHMENTS
    / \

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Rik van Riel]

On Tue, 23 Apr 2002, Christian Smith wrote:

> The question becomes, how much work would it be to rip out the Linux MM
> piece-meal, and replace it with an implementation of UVM?

I doubt we want the Mach pmap layer.

It should be much easier to reimplement the pageout parts of
the BSD memory management on top of a simpler reverse mapping
system.

You can get that code at  http://surriel.com/patches/

cheers,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Christian Smith]

On Tue, 23 Apr 2002, Rik van Riel wrote:

>On Tue, 23 Apr 2002, Christian Smith wrote:
>
>> The question becomes, how much work would it be to rip out the Linux MM
>> piece-meal, and replace it with an implementation of UVM?
>
>I doubt we want the Mach pmap layer.

Why not? It'd surely make porting to new architecures easier (not that
I've tried it either way, mind) is there is a clearly defined MMU
interface. Pmap can hide the differences between forward mapping page
table, TLB or inverted page table lookups, can do SMP TLB shootdown 
transparently. If not the Mach pmap layer, then surely another pmap-like 
layer would be beneficial.

It can handle sparse address space management without the hackery of 
n-level page tables, where a couple of years ago, 3 levels was enough for 
anyone, but now we're not so sure.

The n-level page table doesn't fit in with a high level, platform 
independant MM, and doesn't easily work for all classes of low level MMU. 
It doesn't really scale up or down.

Read the papers on UVM at:
 http://www.ccrc.wustl.edu/pub/chuck/tech/uvm

>
>It should be much easier to reimplement the pageout parts of
>the BSD memory management on top of a simpler reverse mapping
>system.

Agreed.

>
>You can get that code at  http://surriel.com/patches/
>
>cheers,
>
>Rik
>

-- 
    /"\
    \ /    ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL 
     X                           - AGAINST MS ATTACHMENTS
    / \

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Rik van Riel]

On Wed, 24 Apr 2002, Christian Smith wrote:
> On Tue, 23 Apr 2002, Rik van Riel wrote:
> >On Tue, 23 Apr 2002, Christian Smith wrote:
> >
> >> The question becomes, how much work would it be to rip out the Linux MM
> >> piece-meal, and replace it with an implementation of UVM?
> >
> >I doubt we want the Mach pmap layer.
>
> Why not? It'd surely make porting to new architecures easier (not that
> I've tried it either way, mind)

You really need to read the pmap code and interface instead
of repeating the statements made by other people. Have you
ever taken a close look at the overhead implicit in the pmap
layer ?


> interface. Pmap can hide the differences between forward mapping page
> table, TLB or inverted page table lookups, can do SMP TLB shootdown
> transparently. If not the Mach pmap layer, then surely another pmap-like
> layer would be beneficial.

Then how about the Linux pmap layer ?

The datastructure is a radix tree, which happens to map 1 to 1
with the MMU on most architectures. On architectures that don't
have forward page tables Linux fills in the hardware's translation
tables with data from those radix trees.


> It can handle sparse address space management without the hackery of
> n-level page tables, where a couple of years ago, 3 levels was enough for
> anyone, but now we're not so sure.
>
> The n-level page table doesn't fit in with a high level, platform
> independant MM, and doesn't easily work for all classes of low level MMU.
> It doesn't really scale up or down.

Do you have any arguments or are you just repeating what you
read somewhere else ?

Just think about it for a second ... the radix tree structure
of page tables are as good a datastructure as any other.

The mythical "sparse mappings" seem to be very rare in real
life and I'm not convinced they are a reason to change all of
our VM.


regards,

Rik
-- 
	http://www.linuxsymposium.org/2002/
"You're one of those condescending OLS attendants"
"Here's a nickle kid.  Go buy yourself a real t-shirt"

http://www.surriel.com/		http://distro.conectiva.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Momchil Velikov]

>>>>> "Rik" == Rik van Riel <riel@conectiva.com.br> writes:

Rik> On Wed, 24 Apr 2002, Christian Smith wrote:
>> On Tue, 23 Apr 2002, Rik van Riel wrote:
>> >On Tue, 23 Apr 2002, Christian Smith wrote:
>> >
>> >> The question becomes, how much work would it be to rip out the Linux MM
>> >> piece-meal, and replace it with an implementation of UVM?
>> >
>> >I doubt we want the Mach pmap layer.
>> 
>> Why not? It'd surely make porting to new architecures easier (not that
>> I've tried it either way, mind)

Rik> You really need to read the pmap code and interface instead
Rik> of repeating the statements made by other people. Have you
Rik> ever taken a close look at the overhead implicit in the pmap
Rik> layer ?

Actually, on ia32, there's no reason for the pmap layer to be any
different than the Linux radix tree. The overhead argument does not
stand.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Rik van Riel]

On 24 Apr 2002, Momchil Velikov wrote:

> Rik> You really need to read the pmap code and interface instead
> Rik> of repeating the statements made by other people. Have you
> Rik> ever taken a close look at the overhead implicit in the pmap
> Rik> layer ?
>
> Actually, on ia32, there's no reason for the pmap layer to be any
> different than the Linux radix tree. The overhead argument does not
> stand.

So how do you run a pmap VM without duplicating the data from
the pmap layer into the page tables ?

Remember that for VM info the page tables -are- the radix tree.

regards,

Rik
-- 
	http://www.linuxsymposium.org/2002/
"You're one of those condescending OLS attendants"
"Here's a nickle kid.  Go buy yourself a real t-shirt"

http://www.surriel.com/		http://distro.conectiva.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Momchil Velikov]

>>>>> "Rik" == Rik van Riel <riel@conectiva.com.br> writes:

Rik> On 24 Apr 2002, Momchil Velikov wrote:
Rik> You really need to read the pmap code and interface instead
Rik> of repeating the statements made by other people. Have you
Rik> ever taken a close look at the overhead implicit in the pmap
Rik> layer ?
>> 
>> Actually, on ia32, there's no reason for the pmap layer to be any
>> different than the Linux radix tree. The overhead argument does not
>> stand.

Rik> So how do you run a pmap VM without duplicating the data from
Rik> the pmap layer into the page tables ?

Rik> Remember that for VM info the page tables -are- the radix tree.

And the page tables -are- the pmap layer :)

Regards,
-velco
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[William Lee Irwin III]

>>>>> "Rik" == Rik van Riel <riel@conectiva.com.br> writes:
> Rik> So how do you run a pmap VM without duplicating the data from
> Rik> the pmap layer into the page tables ?
> Rik> Remember that for VM info the page tables -are- the radix tree.

On Wed, Apr 24, 2002 at 06:16:01PM +0300, Momchil Velikov wrote:
> And the page tables -are- the pmap layer :)

Yes and no; pagetables-as-ADT normally hides the structure and provides
a canned set of operations on them. Linux just standardizes the data
structure and open-codes access to them in generic code.

One could conceive of a pmap/HAT/whatever -like layer that did little
more than break off copy_page_range(), zap_page_range(), and a few
others into their own file and rename them. At that point it's too
minor of a change to warrant actually carrying it through, unless
one is particularly concerned about radix tree walking obscuring
other operations with actual semantic content. (And it's unclear that
it would get very good coverage on that front anyway.)


Cheers,
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Christian Smith]

On Wed, 24 Apr 2002, Rik van Riel wrote:

>On Wed, 24 Apr 2002, Christian Smith wrote:
>> On Tue, 23 Apr 2002, Rik van Riel wrote:
>> >On Tue, 23 Apr 2002, Christian Smith wrote:
>> >
>> >> The question becomes, how much work would it be to rip out the Linux MM
>> >> piece-meal, and replace it with an implementation of UVM?
>> >
>> >I doubt we want the Mach pmap layer.
>>
>> Why not? It'd surely make porting to new architecures easier (not that
>> I've tried it either way, mind)
>
>You really need to read the pmap code and interface instead
>of repeating the statements made by other people. Have you
>ever taken a close look at the overhead implicit in the pmap
>layer ?

Just how much overhead is there? The only overhead that would come into 
play would/should be when:
- On a TLB based MMU, when there is a soft page fault and a pmap 
  implementation doesn't cache translations over and above those in the 
  TLB.
- Inverted page table when the required <address_space,virtual_address> 
  lookup fails.
- When mapping in a new page after a hard page fault (small compared to 
  the overhead of paging in from backing store.)

>
>
>> interface. Pmap can hide the differences between forward mapping page
>> table, TLB or inverted page table lookups, can do SMP TLB shootdown
>> transparently. If not the Mach pmap layer, then surely another pmap-like
>> layer would be beneficial.
>
>Then how about the Linux pmap layer ?
>
>The datastructure is a radix tree, which happens to map 1 to 1
>with the MMU on most architectures. On architectures that don't
>have forward page tables Linux fills in the hardware's translation
>tables with data from those radix trees.

Thus resulting in redundant information. The benefit of the pmap/hat 
is that on architectures with forward mapping, this can be used as is, 
whereas other MMU architectures can dispense with the middle man 
completely.

For a "pmap" interface, the "Linux pmap" is horribly complex. Not only the 
fact that it is a three level page table, but also that fact that it 
contains swap information.

It's a similar situation to what <4.4BSD was in, when they had their VAX
based paging VM. Upon moving to Mach VM, they could do all sorts of
optimasations that were simply not viable with the old VM, and improved
performance significantly, as well as simplified maintainance and eased
porting.

Same with SunOS's hat based VM, Same with SysV when they inherited the
SunOS VM.

About the only other major OS I know of that uses the page table as their 
primary VM management data structure is the NT kernel.

When it comes down to it, the platform independant part of VM works with
address space identifiers, virtual addresses, physical addresses and
protection attributes. That should then be all the pmap interface exposes,
and is indeed all that the Mach pmap interface exposes. A clean 
seperation.

>
>
>> It can handle sparse address space management without the hackery of
>> n-level page tables, where a couple of years ago, 3 levels was enough for
>> anyone, but now we're not so sure.
>>
>> The n-level page table doesn't fit in with a high level, platform
>> independant MM, and doesn't easily work for all classes of low level MMU.
>> It doesn't really scale up or down.
>
>Do you have any arguments or are you just repeating what you
>read somewhere else ?

And an argument I've read is any less valid because...

Actually, the scaling issue is something I've thought about as I have an 
interest in small systems, that don't really want to be wasting pages for 
page tables that can't be discarded or reused until they are finished 
with. With the current Linux VM, page tables are not discardable or 
reusable. With an opaque pmap interface, page tables can be discarded if 
they haven't been used for a while and the subsequent free memory used 
elsewhere.

Similarly for big systems, a server with hundreds of processes has to keep 
all the page tables resident, even if most of the processes are idle 
99.9% of the time.

>
>Just think about it for a second ... the radix tree structure
>of page tables are as good a datastructure as any other.
>
>The mythical "sparse mappings" seem to be very rare in real
>life and I'm not convinced they are a reason to change all of
>our VM.

I'm worried that the rmap fix is a band-aid on a hacked i386 based VM
system. Rather than trying to adapt a previously hacked solution, it might 
be better just to wipe the slate clean.

>
>
>regards,
>
>Rik
>

-- 
    /"\
    \ /    ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL 
     X                           - AGAINST MS ATTACHMENTS
    / \



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Daniel Phillips]

On Wednesday 24 April 2002 02:46, Rik van Riel wrote:
> On Tue, 23 Apr 2002, Christian Smith wrote:
> 
> > The question becomes, how much work would it be to rip out the Linux MM
> > piece-meal, and replace it with an implementation of UVM?
> 
> I doubt we want the Mach pmap layer.
> 
> It should be much easier to reimplement the pageout parts of
> the BSD memory management on top of a simpler reverse mapping
> system.
> 
> You can get that code at  http://surriel.com/patches/

Another aspect of the (Free)BSD mm we probably want to hijack is the process
management, i.e., throttling processes selectively (and in some kind of fair
rotation) to reduce mm thrashing, which is known to improve throughput in high
load situations.

-- 
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Daniel Phillips]

On Wednesday 24 April 2002 12:50, Christian Smith wrote:
> On Tue, 23 Apr 2002, Rik van Riel wrote:
> >On Tue, 23 Apr 2002, Christian Smith wrote:
> >
> >> The question becomes, how much work would it be to rip out the Linux MM
> >> piece-meal, and replace it with an implementation of UVM?
> >
> >I doubt we want the Mach pmap layer.
> 
> Why not?

Because we use the page tables as part of our essential vm bookkeeping, thus
eliminating the whole UVM/mach 'memory objects' layer.  There was only ever
one trick the memory objects layer could do that we could not with our simple
page table based approach, that being page table sharing.  And now we've found
a way to do that as well, so there is no longer a single advantage to the
memory object strategy, while there is a lot of hard-to-read-and-maintain code
associated with it, and bookkeeping overhead.  (Note I'm not talking about the
rmap aspect here - that's overhead that buys us something tangible - we
think.)

> It'd surely make porting to new architecures easier

It doesn't really.  Ask Linus if you need to know in gory detail why, or
better, search the lkml archives.  This comes up regularly, and imho, Linus
is clearly correct here, both on theoretical grounds and in practice.

In fact, we do have our own abstraction, which is simply a per-architecture
implementation of the basic page table editing operations.  On architectures
that support it (ia32, uml, others) the hardware interprets the page tables
directly.  Otherwise, the contents of the generic page tables are forwarded
incrementally to the real hardware page tables.

Sticking strictly to the ia32 page table model *is* going to break
eventually, however it hasn't yet and we have plenty of time to generalize
the page table model when needed.  Note: 'generalize', not 'lather on a new
layer'.

> (not that
> I've tried it either way, mind) is there is a clearly defined MMU
> interface. Pmap can hide the differences between forward mapping page
> table, TLB or inverted page table lookups,

Not only hide, but interfere with.  For example, in my page table sharing
patch I treat page directories as first-class objects, with ref counts and
individual locks.  How do we extend the pmap api to accomodate that?

> can do SMP TLB shootdown 
> transparently.

But we already do that per-architecture, with a generic api.

> If not the Mach pmap layer, then surely another pmap-like 
> layer would be beneficial.

How about the one we already have?

> It can handle sparse address space management without the hackery of 
> n-level page tables, where a couple of years ago, 3 levels was enough for 
> anyone, but now we're not so sure.

This is true, however we don't need to add a new layer to deal with that,
just generalize the existing one.  You want to be very careful about where
you draw that boundaries, to avoid becoming hampered by the lowest common
denoninator effect.

> The n-level page table doesn't fit in with a high level, platform 
> independant MM, and doesn't easily work for all classes of low level MMU. 
> It doesn't really scale up or down.

I don't agree with 'doesn't scale down'.  I partially agree with 'doesn't
scale up'.  *However*, whatever bookkeeping structure we ultimately end up
with, it has to permit efficient processing in VM order - otherwise how are
you going to implement zap_page_range for example?  So it's going to stay
as some kind of tree, though it doesn't have to remain as rigidly defined
as it now is.

> Read the papers on UVM at:
>  http://www.ccrc.wustl.edu/pub/chuck/tech/uvm

Been there, done that :-)

-- 
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Rik van Riel]

On Sun, 5 May 2002, Daniel Phillips wrote:

> Another aspect of the (Free)BSD mm we probably want to hijack is the
> process management, i.e., throttling processes selectively (and in some
> kind of fair rotation) to reduce mm thrashing, which is known to improve
> throughput in high load situations.

We absolutely need something like this, but I'm not sure we'll want
the policy FreeBSD has or one of the many others.

As for the mechanism ... I've had that up and running for about a
year now.

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Christian Smith]

I can clearly see this is flogging a dead horse, so I'll let it lie, save
the following observations and comments inline:
- The Linux VM is very difficult to pick up. Maybe not conceptually, but 
  the implementation is a nightmare to follow. That's probably why it's so 
  poorly documented.
- While rmap is the way to go, it's still more of a band-aid than an 
  intergrated solution.
- do_page_fault() is definately in the wrong place, or at least, the work 
  it does (it finds the generic vma of the fault. This should be generic 
  code.)
- Most people appear to be aiming towards absolute speed in all cases, 
  without considering the wider picture. Anything that makes choosing the 
  correct page to page out will out do any level of code optimisation due 
  to the obvious limits to IO speed. Looking at Linux VM performance 
  against any of the BSDs and SysV should indicate that a split generic 
  VM/pmap layer is easier to optimise for the heavy load conditions, not
  to mention maintain.
- I find this a fascinating discussion. If anyone fancies posting any 
  pointers to detailed Linux VM docs, that'd be great. I don't want to 
  swamp the list with this, so I'm happy to take anything off list (IRC?)

Finally, I'm not dissing anyone's work, especially not the rmap work from 
Rik. I just think there's a better way, and the stability problems of 
earlier 2.4.x kernels might have been avoided with a simpler VM.

Christian

On Sun, 5 May 2002, Daniel Phillips wrote:

>On Wednesday 24 April 2002 12:50, Christian Smith wrote:
>> On Tue, 23 Apr 2002, Rik van Riel wrote:
>> >On Tue, 23 Apr 2002, Christian Smith wrote:
>> >
>> >> The question becomes, how much work would it be to rip out the Linux MM
>> >> piece-meal, and replace it with an implementation of UVM?
>> >
>> >I doubt we want the Mach pmap layer.
>> 
>> Why not?
>
>Because we use the page tables as part of our essential vm bookkeeping, thus
>eliminating the whole UVM/mach 'memory objects' layer.  There was only ever
>one trick the memory objects layer could do that we could not with our simple
>page table based approach, that being page table sharing.  And now we've found
>a way to do that as well, so there is no longer a single advantage to the
>memory object strategy, while there is a lot of hard-to-read-and-maintain code
>associated with it, and bookkeeping overhead.  (Note I'm not talking about the
>rmap aspect here - that's overhead that buys us something tangible - we
>think.)

IMHO, page tables are not the place to hold this bookkeeping information.

My interest was in replacing, completely, the VM and using a memory object
like layer. With that would come the need for a pmap like layer.

Another benefit to the memory object approach is that memory objects are a
more logical representation of a file mapping, which is essentially what
most memory is (anonymous memory could be thought of as a mapping of an
anonymouse backed by swap space.) This intergrates VM/VFS memory usage.

VFS already knows which pages of an object are mapped. Memory objects 
would be a simple layer on top of that. This doesn't happen in Linux, as 
far as I can fathom.

>
>> It'd surely make porting to new architecures easier
>
>It doesn't really.  Ask Linus if you need to know in gory detail why, or
>better, search the lkml archives.  This comes up regularly, and imho, Linus
>is clearly correct here, both on theoretical grounds and in practice.

Except to port a pmap interface, you need to know only the pmap interface
and target processor. To port Linux VM, you need to know a complex data
structure and associated manipulation API, which may change in future.

>
>In fact, we do have our own abstraction, which is simply a per-architecture
>implementation of the basic page table editing operations.  On architectures
>that support it (ia32, uml, others) the hardware interprets the page tables
>directly.  Otherwise, the contents of the generic page tables are forwarded
>incrementally to the real hardware page tables.
>
>Sticking strictly to the ia32 page table model *is* going to break
>eventually, however it hasn't yet and we have plenty of time to generalize
>the page table model when needed.  Note: 'generalize', not 'lather on a new
>layer'.

I still find this a blinkered outlook. Pmap isn't even a new layer that 
shouldn't be there. There really should be a generic/non-generic split (yes,
I know the page table stuff if generic.)

>
>> (not that
>> I've tried it either way, mind) is there is a clearly defined MMU
>> interface. Pmap can hide the differences between forward mapping page
>> table, TLB or inverted page table lookups,
>
>Not only hide, but interfere with.  For example, in my page table sharing
>patch I treat page directories as first-class objects, with ref counts and
>individual locks.  How do we extend the pmap api to accomodate that?

I shouldn't care. That's the benefit of an opaque API. If page table space 
is a problem, with pmap I can just dump page directories that haven't been 
used for a while (the information would be a redundant copy of the upper
level generic VM.) Afterall, a sleeping process is not going to need to 
handle page faults. And even running process is unlikely to need all it's
page directories at once.

>
>> can do SMP TLB shootdown 
>> transparently.
>
>But we already do that per-architecture, with a generic api.

Possibly a bad example.

>
>> If not the Mach pmap layer, then surely another pmap-like 
>> layer would be beneficial.
>
>How about the one we already have?

I don't like using a data structure as an 'API'. An API ideally gives you 
an interface to what you need to do, not how it's done. Sure, APIs can 
become obsolete, but function calls are MUCH easier to provide legacy 
support for than a large, complex data structure.

>
>> It can handle sparse address space management without the hackery of 
>> n-level page tables, where a couple of years ago, 3 levels was enough for 
>> anyone, but now we're not so sure.
>
>This is true, however we don't need to add a new layer to deal with that,
>just generalize the existing one.  You want to be very careful about where
>you draw that boundaries, to avoid becoming hampered by the lowest common
>denoninator effect.

The problem is that there are no boundaries at the moment.

>
>> The n-level page table doesn't fit in with a high level, platform 
>> independant MM, and doesn't easily work for all classes of low level MMU. 
>> It doesn't really scale up or down.
>
>I don't agree with 'doesn't scale down'.  I partially agree with 'doesn't
>scale up'.  *However*, whatever bookkeeping structure we ultimately end up
>with, it has to permit efficient processing in VM order - otherwise how are
>you going to implement zap_page_range for example?  So it's going to stay
>as some kind of tree, though it doesn't have to remain as rigidly defined
>as it now is.

As far as scaling down goes, I've given an example above of where page
directories (or whole page tables,) can be discarded to save space. 
Resident pages are managed by the vnode, and can be looked quickly when 
needed using the <vnode,offset> hash. For a small platform, it may be 
beneficial to sacrifice page table space when the information is 
redundant. In this sense, the pmap data is simply a cache.

Memory objects can easily do VM order processing. But why would it be
necassary? For trancate() of mapped file, rmap or such like can provide a
better way of unmapping the pages. For unmapping of memory, pmap_remove
should fit the bill.

>
>> Read the papers on UVM at:
>>  http://www.ccrc.wustl.edu/pub/chuck/tech/uvm
>
>Been there, done that :-)

Fair enough:)

-- 
    /"\
    \ /    ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL 
     X                           - AGAINST MS ATTACHMENTS
    / \




--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Rik van Riel]

On Tue, 7 May 2002, Christian Smith wrote:

> >> If not the Mach pmap layer, then surely another pmap-like
> >> layer would be beneficial.
> >
> >How about the one we already have?
>
> I don't like using a data structure as an 'API'. An API ideally gives
> you an interface to what you need to do, not how it's done. Sure, APIs
> can become obsolete, but function calls are MUCH easier to provide
> legacy support for than a large, complex data structure.

OK, this I can agree with.

I'd be interested in working with you towards a way of
hiding some of the data structure manipulation behind
a more abstract interface, kind of like what I've done
with the -rmap stuff ... nothing outside of rmap.c
knows about struct pte_chain and nothing should know.

If you could help find ways in which we can abstract
out manipulation of some more data structures I'd be
really happy to help implement and clean up stuff.

kind regards,

Rik
-- 
	http://www.linuxsymposium.org/2002/
"You're one of those condescending OLS attendants"
"Here's a nickle kid.  Go buy yourself a real t-shirt"

http://www.surriel.com/		http://distro.conectiva.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[William Lee Irwin III]

On Tue, 7 May 2002, Christian Smith wrote:
>> I don't like using a data structure as an 'API'. An API ideally gives
>> you an interface to what you need to do, not how it's done. Sure, APIs
>> can become obsolete, but function calls are MUCH easier to provide
>> legacy support for than a large, complex data structure.

On Tue, May 07, 2002 at 04:23:34PM -0300, Rik van Riel wrote:
> OK, this I can agree with.
> I'd be interested in working with you towards a way of
> hiding some of the data structure manipulation behind
> a more abstract interface, kind of like what I've done
> with the -rmap stuff ... nothing outside of rmap.c
> knows about struct pte_chain and nothing should know.
> If you could help find ways in which we can abstract
> out manipulation of some more data structures I'd be
> really happy to help implement and clean up stuff.
> kind regards,

Procedural interfaces to pagetable manipulations are largely what
the BSD pmap and SVR4 HAT layers consisted of, no?

Cheers,
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Daniel Phillips]

On Tuesday 07 May 2002 20:37, Christian Smith wrote:
> I can clearly see this is flogging a dead horse, so I'll let it lie, save
> the following observations and comments inline:
> - The Linux VM is very difficult to pick up. Maybe not conceptually, but 
>   the implementation is a nightmare to follow. That's probably why it's so 
>   poorly documented.

It's poorly documented because the latest edition of Understanding the Linux
Kernel isn't out yet ;-)

Your best sources of documentation at this point are:

  - lxr.linux.no (or source navigator)
  - Andrea's slides
  - Understanding the Linux Kernel (mostly still applies)
  - background links on kernelnewbies.org

> - While rmap is the way to go, it's still more of a band-aid than an 
>   intergrated solution.

Nope, this would indicate you don't have a handled on the fundamental
algorithms.  Switching from virtual scanning to physical scanning is hardly
something you'd describe as a bandaid.

> - do_page_fault() is definately in the wrong place, or at least, the work 
>   it does (it finds the generic vma of the fault. This should be generic 
>   code.)

It's per-arch because different architectures have very different sets of
conditions that have to be handled.  If you like, you can try to break out
some cross-arch factors and make them into inlines or something.  That's
cleanup work that's hard and mostly thankless.  We need more gluttons for
punishment^W^W^W volunteers to tackle this kind of thing.

> - Most people appear to be aiming towards absolute speed in all cases, 
>   without considering the wider picture. Anything that makes choosing the 
>   correct page to page out will out do any level of code optimisation due 
>   to the obvious limits to IO speed. Looking at Linux VM performance 
>   against any of the BSDs and SysV should indicate that a split generic 
>   VM/pmap layer is easier to optimise for the heavy load conditions, not
>   to mention maintain.

The FreeBSD VM is maybe easy to optimise if you are Matt Dillon, but before
he came along it was a disaster.

The Linux VM is pretty much impossible to optimize for large memory machines
in its current form, that is why the move to switch from virtual scanning
to physical scanning.  Other than that, it's not too bad.

-- 
Daniel

(p.s., it's not really necessary to include the entire thread at the bottom
of each post.)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Daniel Phillips]

On Tuesday 07 May 2002 21:23, Rik van Riel wrote:
> On Tue, 7 May 2002, Christian Smith wrote:
> 
> > >> If not the Mach pmap layer, then surely another pmap-like
> > >> layer would be beneficial.
> > >
> > >How about the one we already have?
> >
> > I don't like using a data structure as an 'API'. An API ideally gives
> > you an interface to what you need to do, not how it's done. Sure, APIs
> > can become obsolete, but function calls are MUCH easier to provide
> > legacy support for than a large, complex data structure.
> 
> OK, this I can agree with.
> 
> I'd be interested in working with you towards a way of
> hiding some of the data structure manipulation behind
> a more abstract interface, kind of like what I've done
> with the -rmap stuff ... nothing outside of rmap.c
> knows about struct pte_chain and nothing should know.
> 
> If you could help find ways in which we can abstract
> out manipulation of some more data structures I'd be
> really happy to help implement and clean up stuff.

The most obvious place to start are the page table walking operations, of
which there are a half-dozen instances or so.  Bill started to do some
work on this, but that ran aground somehow.  I think you might run into
the argument 'not broken yet, so don't fix yet'.  Still, it would be
worth experimenting with strategies.

Personally, I'd consider such work a diversion from the more important task
of getting rmap implemented.

-- 
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Daniel Phillips]

On Tuesday 07 May 2002 21:25, William Lee Irwin III wrote:
> Procedural interfaces to pagetable manipulations are largely what
> the BSD pmap and SVR4 HAT layers consisted of, no?

They factor the interface the wrong way for Linux.  You don't want
to have to search for each (pte *) starting from the top of the
structure.  We need to be able to do bulk processing.  The BSD
interface just doesn't accomodate this.

-- 
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[William Lee Irwin III]

On Tuesday 07 May 2002 20:37, Christian Smith wrote:
>> - do_page_fault() is definately in the wrong place, or at least, the work 
>>   it does (it finds the generic vma of the fault. This should be generic 
>>   code.)

On Tue, May 07, 2002 at 09:37:57PM +0200, Daniel Phillips wrote:
> It's per-arch because different architectures have very different sets of
> conditions that have to be handled.  If you like, you can try to break out
> some cross-arch factors and make them into inlines or something.  That's
> cleanup work that's hard and mostly thankless.  We need more gluttons for
> punishment^W^W^W volunteers to tackle this kind of thing.

I believe I'm already signed up for this, or at least I'm putting down
code on this front.


Cheers,
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Rik van Riel]

On Tue, 7 May 2002, William Lee Irwin III wrote:

> Procedural interfaces to pagetable manipulations are largely what
> the BSD pmap and SVR4 HAT layers consisted of, no?

Indeed, but there is a difference between:

1) we need to get a proper interface

and

2) we should have 2 sets of data structures, one shadowing the other

I like (1), but have my doubts about (2) ...

cheers,

Rik
-- 
	http://www.linuxsymposium.org/2002/
"You're one of those condescending OLS attendants"
"Here's a nickle kid.  Go buy yourself a real t-shirt"

http://www.surriel.com/		http://distro.conectiva.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[William Lee Irwin III]

On Tuesday 07 May 2002 21:25, William Lee Irwin III wrote:
>> Procedural interfaces to pagetable manipulations are largely what
>> the BSD pmap and SVR4 HAT layers consisted of, no?

On Tue, May 07, 2002 at 09:47:28PM +0200, Daniel Phillips wrote:
> They factor the interface the wrong way for Linux.  You don't want
> to have to search for each (pte *) starting from the top of the
> structure.  We need to be able to do bulk processing.  The BSD
> interface just doesn't accomodate this.

Generally the way to achieve this is by anticipating those bulk
operations and providing standardized methods for them. copy_page_range()
and zap_page_range() are already examples of this. For other cases,
it's perhaps a useful layer inversion.


Cheers,
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Rik van Riel]

On Tue, 7 May 2002, Daniel Phillips wrote:

> The most obvious place to start are the page table walking operations,
> of which there are a half-dozen instances or so.  Bill started to do
> some work on this, but that ran aground somehow.  I think you might run
> into the argument 'not broken yet, so don't fix yet'.  Still, it would
> be worth experimenting with strategies.
>
> Personally, I'd consider such work a diversion from the more important
> task of getting rmap implemented.

They're orthagonal.  If we find somebody to implement the
stuff it's easy enough to just merge it everywhere.

In fact, I'm pretty sure that if we get this stuff
abstracted out properly it should be easier to get -rmap
merged and improved.

cheers,

Rik
-- 
	http://www.linuxsymposium.org/2002/
"You're one of those condescending OLS attendants"
"Here's a nickle kid.  Go buy yourself a real t-shirt"

http://www.surriel.com/		http://distro.conectiva.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[William Lee Irwin III]

On Tue, 7 May 2002, William Lee Irwin III wrote:
>> Procedural interfaces to pagetable manipulations are largely what
>> the BSD pmap and SVR4 HAT layers consisted of, no?

On Tue, May 07, 2002 at 04:49:08PM -0300, Rik van Riel wrote:
> Indeed, but there is a difference between:
> 1) we need to get a proper interface
> and
> 2) we should have 2 sets of data structures, one shadowing the other
> I like (1), but have my doubts about (2) ...

If such schemes were implemented and (2) occurred, IMHO it would be
pessimal and should not be merged.

Cheers,
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[William Lee Irwin III]

On Tue, May 07, 2002 at 09:43:29PM +0200, Daniel Phillips wrote:
> The most obvious place to start are the page table walking operations, of
> which there are a half-dozen instances or so.  Bill started to do some
> work on this, but that ran aground somehow.  I think you might run into
> the argument 'not broken yet, so don't fix yet'.  Still, it would be
> worth experimenting with strategies.
> Personally, I'd consider such work a diversion from the more important task
> of getting rmap implemented.

There are a couple of things I should probably say about my prior efforts.

The plan back then was to hide the pagetable structure from generic code
altogether and allow architecture-specific code to export a procedural
interface totally insulating the core from the structure of pagetables.
This was largely motivated by the notion that the optimal pagetable
structure could be chosen on a per-architecture basis. Linus himself
informed me that there was evidence to the contrary regarding
architecture-specific optimal pagetable structures, and so I abandoned
that effort given the evidence the scheme was pessimal.

I have no plans now to change the standardized structure or to export
a HAT from arch code. OTOH I've faced some recent reminders of what the
code looks like now and believe janitoring may well be in order.

Cheers,
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Daniel Phillips]

On Tuesday 07 May 2002 21:50, William Lee Irwin III wrote:
> On Tuesday 07 May 2002 21:25, William Lee Irwin III wrote:
> >> Procedural interfaces to pagetable manipulations are largely what
> >> the BSD pmap and SVR4 HAT layers consisted of, no?
> 
> On Tue, May 07, 2002 at 09:47:28PM +0200, Daniel Phillips wrote:
> > They factor the interface the wrong way for Linux.  You don't want
> > to have to search for each (pte *) starting from the top of the
> > structure.  We need to be able to do bulk processing.  The BSD
> > interface just doesn't accomodate this.
> 
> Generally the way to achieve this is by anticipating those bulk
> operations and providing standardized methods for them. copy_page_range()
> and zap_page_range() are already examples of this. For other cases,
> it's perhaps a useful layer inversion.

What I'm really talking about is how you'd reimplement copy_page_range,
zap_page_range, and the other 4-5 primitives that use the 3 nested loops
style of traversing the i86-style page table structure.

-- 
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Daniel Phillips]

On Tuesday 07 May 2002 21:51, Rik van Riel wrote:
> On Tue, 7 May 2002, Daniel Phillips wrote:
> 
> > The most obvious place to start are the page table walking operations,
> > of which there are a half-dozen instances or so.  Bill started to do
> > some work on this, but that ran aground somehow.  I think you might run
> > into the argument 'not broken yet, so don't fix yet'.  Still, it would
> > be worth experimenting with strategies.
> >
> > Personally, I'd consider such work a diversion from the more important
> > task of getting rmap implemented.
> 
> They're orthagonal. If we find somebody to implement the
> stuff it's easy enough to just merge it everywhere.

It's not orthogonal, it's very inconvenient to have the superficial structure
of the vm ops changing while working on deep changes.  It makes it really hard
to do regression testing.  Parallel dvelopment I'd buy - somebody can be working
this out at the same time, then merge *after* the rmap work is completed.  The
current nested-loop approach isn't broken yet.

> In fact, I'm pretty sure that if we get this stuff
> abstracted out properly it should be easier to get -rmap
> merged and improved.

Color me skeptical about that.

-- 
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Daniel Phillips]

On Tuesday 07 May 2002 23:21, William Lee Irwin III wrote:
> There are a couple of things I should probably say about my prior efforts.
> 
> The plan back then was to hide the pagetable structure from generic code
> altogether and allow architecture-specific code to export a procedural
> interface totally insulating the core from the structure of pagetables.
> This was largely motivated by the notion that the optimal pagetable
> structure could be chosen on a per-architecture basis. Linus himself
> informed me that there was evidence to the contrary regarding
> architecture-specific optimal pagetable structures, and so I abandoned
> that effort given the evidence the scheme was pessimal.
> 
> I have no plans now to change the standardized structure or to export
> a HAT from arch code. OTOH I've faced some recent reminders of what the
> code looks like now and believe janitoring may well be in order.

Swap_off is deeply disgusting and needs a rototilling.  Some others like
copy_page_range and remap_page_range are fine.  Zap_page_range has
superficial defects.  Other than swap_off, there are no really obviously
bleeding wounds.

-- 
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[William Lee Irwin III]

On Tuesday 07 May 2002 21:50, William Lee Irwin III wrote:
>> Generally the way to achieve this is by anticipating those bulk
>> operations and providing standardized methods for them. copy_page_range()
>> and zap_page_range() are already examples of this. For other cases,
>> it's perhaps a useful layer inversion.

On Wed, May 08, 2002 at 01:02:02AM +0200, Daniel Phillips wrote:
> What I'm really talking about is how you'd reimplement copy_page_range,
> zap_page_range, and the other 4-5 primitives that use the 3 nested loops
> style of traversing the i86-style page table structure.

Why reimplement when you can rename? =)

These guys aren't really the culprits. By and large the pagetables are
just overused and overexposed; things that aren't speed critical should
probably just pass callbacks into a generic walker if they absolutely
have to walk pagetables. i.e. if you aren't the VM, don't do this.
Walking pagetables is horribly slow anyway, zap_page_range() has
ridiculous latencies. Shoving these guys off into their own module
would likely be enough for the moment.


Cheers,
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Andrew Morton]

William Lee Irwin III wrote:
> 
> zap_page_range() has ridiculous latencies.

prefetch in zap_pte_range() would help?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Momchil Velikov]

>>>>> "Daniel" == Daniel Phillips <phillips@bonn-fries.net> writes:

Daniel> On Tuesday 07 May 2002 21:25, William Lee Irwin III wrote:
>> Procedural interfaces to pagetable manipulations are largely what
>> the BSD pmap and SVR4 HAT layers consisted of, no?

Daniel> They factor the interface the wrong way for Linux.  You don't want
Daniel> to have to search for each (pte *) starting from the top of the
Daniel> structure.  We need to be able to do bulk processing.  The BSD
Daniel> interface just doesn't accomodate this.

FWIW, UVM has a mechanism to traverse all the mapped pages, as opposed
to traversing all the addresses and checking of there is a page.

My 2c,
-velco
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Daniel Phillips]

On Wednesday 08 May 2002 09:59, Momchil Velikov wrote:
> >>>>> "Daniel" == Daniel Phillips <phillips@bonn-fries.net> writes:
> 
> Daniel> On Tuesday 07 May 2002 21:25, William Lee Irwin III wrote:
> >> Procedural interfaces to pagetable manipulations are largely what
> >> the BSD pmap and SVR4 HAT layers consisted of, no?
> 
> Daniel> They factor the interface the wrong way for Linux.  You don't want
> Daniel> to have to search for each (pte *) starting from the top of the
> Daniel> structure.  We need to be able to do bulk processing.  The BSD
> Daniel> interface just doesn't accomodate this.
> 
> FWIW, UVM has a mechanism to traverse all the mapped pages, as opposed
> to traversing all the addresses and checking of there is a page.

To make this concrete, what would copy_page_range look like, using this
mechanism?

-- 
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Rik van Riel]

On Wed, 8 May 2002, Daniel Phillips wrote:

> To make this concrete, what would copy_page_range look like, using this
> mechanism?

Or maybe copy_page_range should be behind this mechanism and
modify the data structures directly ?

Remember that the goal is not to abstract out all of the VM,
the goal is to make _most_ of the VM more readable and maintainable.

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Daniel Phillips]

On Wednesday 08 May 2002 16:43, Rik van Riel wrote:
> On Wed, 8 May 2002, Daniel Phillips wrote:
> 
> > To make this concrete, what would copy_page_range look like, using this
> > mechanism?
> 
> Or maybe copy_page_range should be behind this mechanism and
> modify the data structures directly ?

It already modifies the data structures directly.  You're proposing that 
copy_page_range should be per_arch?

> Remember that the goal is not to abstract out all of the VM,
> the goal is to make _most_ of the VM more readable and maintainable.

remap_page_range has the same problem.  So which of the bulk memory 
operations actually gets cleaner?

If the answer to 'can the proposed api handle copy_page_range?' is 'no', then 
it's not a very interesting api.  And by 'handling' I don't mean 'make it 
per-arch', that's going backwards.

-- 
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: Why *not* rmap, anyway?

[Rik van Riel]

On Wed, 8 May 2002, Daniel Phillips wrote:
> On Wednesday 08 May 2002 16:43, Rik van Riel wrote:
> > On Wed, 8 May 2002, Daniel Phillips wrote:
> >
> > > To make this concrete, what would copy_page_range look like, using this
> > > mechanism?
> >
> > Or maybe copy_page_range should be behind this mechanism and
> > modify the data structures directly ?
>
> It already modifies the data structures directly.  You're proposing that
> copy_page_range should be per_arch?

No. I'm not proposing that data structures should be different
per arch.

All I'm interested in is separating parts of the VM from each
other.

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/