Re: Task server, physmem, pagers

[Marcus Brinkmann]

At Thu, 15 Jul 2004 00:10:44 +0200,
Bas Wijnen wrote:
> Am I right that physmem is just doing (per page) malloc and free for tasks, by
> mapping memory to them?

That's an oversimplification, but it's one of the things it does, yes.
 
> Should every task start its own pager?

Yes, but pagers are not tasks, but threads within the same task.

> If so, should the task server start
> pagers for itself and for physmem when it boots?

physmem runs on all the physical memory that exists, so obviously
there is no paging to do.  If you were to support more than 3 GB of
memory on ia32, you'd probably need some sort of pager in physmem, but
that's a side-issue.

Likewise, the task server will run on wired memory and not swap out
pages.  It will need some sort of memory manager, but it can be very
simple.  Making the task server's memory swappable is a nasty thing to
attempt.  Imagine the task server master thread page faulting, sending
a message to physmem, which just at this time tries to create a new
RPC service thread... you can probably make some very clever
hierarchies to overcome such problems, but I doubt it's worth it.

> Why doesn't wortel start physmem's pager?

See above.

> It starts its worker threads as well, after all.  Speaking
> of that, I think I would like it better if physmem would have to ask wortel to
> do that, instead of wortel just giving 3 extra threads.  A different physmem
> implementation could need more or less threads, and it doesn't sound right to
> me if wortel needs to be changed for that.

The issue with that is that it requires that you add some hacks to the
thread implementation to do that if there are no more threads.
Normally, the thread implementation will ask the task server, but
before that is running, it should ask wortel (in your opinion).  That
is just dead code, because it is only needed at bootstrap.

The number 3 is not arbitrary.  It's the main thread, the RPC manager
thread, and one worker thread.  That's enough to run on until the task
server is up, because the task server will run single threaded (and
thus make serialized requests to physmem) until it's up and running
fully, and maybe even beyond that.

Now, I agree that it is not so good to hard-code this into the wortel
binary.  My idea was to make it a fake (script) argument on the module
command line for physmem, like this: "physmem $(init-threads=3)" or
whatever, which wortel could parse.  That's flexible enough without
adding total dynamic thread allocation, which is really unnecessary.

> Just to be sure, (a begin of) the bootup timeline as I see it:
> - L4 starts sigma0
> - L4 starts wortel
> - wortel starts physmem
> - wortel helps physmem boot, providing threads, giving it memory, etc

- physmem gives container caps to wortel

> - wortel starts task

- wortel helps task boot
- task talks to physmem for the first time
- task provides wortel with task caps

> - wortel passes physmem's task capability to physmem
> - task uses physmem to start its worker threads for its capability server
>   (physmem already has its task server cap, so task doesn't have to be
>    operational for this)

Not sure I understand that last point.

Marcus