Re: Questions

[Marcus Brinkmann]

Hi,

Neal doesn't seem to bite quickly, so I'll give it a shot.

At Thu, 28 Oct 2004 18:57:04 +0200,
Martin Schaffner <address@hidden> wrote:
> What happens if a task that has to return extra pages does not get the  
> chance to do so, because it does not get any time slice?

Good question, and we don't have any specific answer to that for now.
There was some discussion on this in the past days on this forum.

You could have physmem interact with the scheduler at a pretty low
level to guarantee that the task had a fair chance and amount of cpu
cycles.

> Further, if it  
> does get a timeslice, how does the developer assure that the actions,  
> which the programs does to make the eviction decision, fit into the  
> given time? As there is no time to do any swapping, I guess all  
> operations that lead to the decision will have to only access memory of  
> guaranteed pages. How does the developer assure that the algorithm is  
> fast enough, and that this holds on all architectures that GNU/L4 runs  
> on?

Interesting point.  You couldn't even swap in pages, true.  You will
have to make sure that you always keep a list of all pages you
consider to be extra in resident memory, and that you will find the
pages you want to kick out first soon.

Let me suggest a model to you: Imagine every task would have a
dedicated page on which it records all pages it considers to be extra.
The page would be logically shared with physmem (ie, physmem would
know which page it is), and could access and read it, and know which
pages it lists.  On the page is a shared mutex that must be locked
when updating the page.

So, when the user wants to modify the list of extra pages (resort them
to vary the priority, or add/remove/exchange entries), it takes the
lock and performs the operation.  If physmem wants to read the list,
it takes the lock with a timeout.  If the timeout expires, the task is
in violation of the protocol.

Or, another model: Use some shared memory protocol to update the data.
Then physmem and the task can access it concurrently without looking.
When physmem does not find enough extra pages on the page, the task is
in violation of the protocol.  In this case, no locking takes place,
so no timeout is needed.  The task would have to make sure that the
list always contains at least as many pages as its extra page count.

I don't have thought about such a shared memory protocol, but my gut
feeling is that it is theoretically possible.  To actually update the
list, it may be necessary for the task to first add the new item, then
remove the old one (so that the total count never drops below the
extra page count).  But that is an acceptable restriction in my
opinion, esp if you first reorder things so that the old page which
you want to remove comes last, and add the new one at a higher
priority: Then physmem will never pick that one, as it will only pick
as many as your total extra page count.

This is a new idea by me, so we have not thought about it yet.  But
it's one possible approach, that has the right semantics and doesn't
require a timeout.  So, we are still looking at solutions to this.

> Which task owns the version specifier of a container? What makes sure  
> that a container's version is incremented on container_copy_in? is this  
> done by a physmem, or another trusted server?

I am not sure the version specifier is still needed or even part of
the design.  But my understanding is/was that it is owned and
protected by physmem, and automatically increased for certain
operations.
 
> Is it possible that a task does (UNSIGNED_INT_MAX - 1) operations on a  
> container to reset its value, to cover up an operation?

I like your scrutiny.  But I think that in the context of this old
version of Neal's design, the counter would be verified long before
you could perform so many operations.
 
> Can the owner of a container bypass the usual library and access it  
> without touching its version? Is this not a problem because of the  
> container locking mechanism?

The version would be stored and protected in physmem, not in the user
task.
 
> Can both the owner of the container and the device access the contained  
> memory directly (if it is not locked), thus enabling zero-copy memory  
> transfer?

Yes.  Containers are designed with DMA into the user memory in mind.

> For lock_physical, a device driver has to be privileged. Is it still  
> possible to have device drivers started by users? This could be useful  
> for example for USB devices.

No.  We don't have any particular ideas about untrusted drivers.  You
could write a trusted driver though that allows to communicate with
untrusted drivers, though, if you have ideas on how to do that safely.
 
> Will the adresses pointing inside a container be the same for all its  
> users? If yes, what if there are conflicts (a task tries to map a  
> container, but the container's adresses are already in use by the  
> task)?

There are three types of addresses involved in using containers: The
physical address of the underlying frame.  The offset in the container
of the virtual frame which references the physical frame.  And virtual
addresses in various tasks to which this frame is mapped.

The only address that is stable (sort of) is the offset in the
container.  The physical address can change if physmem reorganizes the
memory.  The virtual addresses are arbitrary and chosen by the user.
(Even the offset in the container can change if you manipulate the
container, ie by moving or copying the virtual frames around - but I
don't think this is what you mean here).

So, no, the addresses are not generally the same, but can be the same
if the users chose to do so.

> If no, is it therefore impossible to directly store a linked  
> list in a container?

If you mean if it is possible to store a linked list in a container
and _share_ it, then only if you always map the container at the same
virtual address.

But containers are not intended to be used in this way in the first place.
 
> Can hurd task use L4 IPCs without restrictions (for example for a  
> single notification), or are they limited to hurdish communication?

Technically, they can use direct L4 IPC.  In general, there are good
reasons to stick to Hurdish RPCs, because those have certain
properties (like, they can be canceled), and it is difficult enough to
implement one IPC mechanism correctly.  Hopefully, the Hurdish RPCs
are generic and fast enough to be usable for a variety of things.
However, nothing stops you from having private protocols and
implementations that are not hurdish, and there may be good reasons
for that (like, if you have two tasks which trust each other, you can
use direct IPC for better performance, if normal shared memory and
hurdish RPC are not fast enough for your application).

Thanks,
Marcus