l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions about copy-on-write


From: Marcus Brinkmann
Subject: Re: Questions about copy-on-write
Date: Wed, 27 Oct 2004 21:33:29 +0200
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

> lazy copy-on-write isn't necessarily a perfomance increase.

Sorry, that was my fault.  Copy-on-write is always a lazy copy.  I was
being redundantly repetitive.

> i think the general understanding has currently bin that 
> mapping/unmapping will be a privilegded operation. ie. only hurd servers 
> should be doing, or most precisely mostly physmem. untrusted tasks won't 
> really be unmapping/mapping, they will be using containers and closing 
> containers, and dying. physmem will take care of the actual business of 
> mapping and copying and etc.

This is a misunderstanding, or maybe a careless wording.  A mapping
operation is always from one task to another, and you don't really say
anything about that, so I don't know if you mean it the right or the
wrong way.

What I say is that in the Hurd a mapping always happens FROM physmem
TO some task, and never from any other task than physmem.  This is not
strictly true yet, but very close and we aim for it.

Physmem will map some memory in a container you have access to if and
only if you request it (this is necessarily so, as physmem can only
install mappings by replying to an RPC you make).

Physmem will unmap memory (except for certain cases of wiring, like
DMA and maybe some others) whenever it wants to (if it wants to) to
shuffle memory around physically.  You won't be notified about it.
You only learn that physmem unmapped something when you page fault.

> physmem will be predictably mature into being a very intelligent and 
> thoughtful program, yet not very complicated as it won't (ideally) 
> contain any policy on memory.

This is not true.  Physmem introduces a lot of policy, for example it
will enforce memory consumption restrictions, and how to share memory.
It will not contain any policy on managing _virtual_ address space of
a task.  But it will contain policy about _physical_ memory management
(hence its name).

> it will only serve as the do-boy for 
> memory, or at least that's the picture i'm seeing painted. but not just 
> any do-boy, a muscular, well-trained, firm and obedient do-boy. if it 
> needs to know something to accurately perform a certain task (like 
> distinguishing which task is the provider of a copy-on-write page) then 
> it will certainly be given this knowledge.

So you think that physmem will be physically well-exercised? :)

Thanks,
Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]