Changing our thread model // resource accounting

[Justus Winter]

Hello :)

with the recent advancements in Subhurd(TM) technology, our lack of
accounting is becoming more and more apparent.  The challenge with
accounting is of course to attribute resources spent to the client
that actually asked some server for some work.

Also, with our current thread model and asynchronous IPC it is really
easy to DOS the server by sending requests, with the server having to
spawn a thread for each request.

One way of relating the servers work to the client is that the client
surrenders its scheduling context to the server, also known under the
way cooler names migrating threads(TM) or thread shuttles(TM).  Under
this model, the client is restricted to synchronous IPC, solving the
DOS as well.

Richard suggests another solution, thread binding.  This is my attempt
to imagine how this might work, with an eye on how to implement it
within our current IPC model and framework code.  Beat me gently with
a XOR-linked list...

Transparent thread binding within the Mach IPC
==============================================

Thread_client             GNU Mach            Thread_server
      |                      |                      |
      |                      |  task_require_bind   |
      |                      |<---------0-----------|
      |                      |                      |
      |   msg_0              |  thread_bind|msg_0   |
      |----------1---------->|----------1'--------->| thread_create
      |                      |                      |------2----->
      |                      |  thread_bind         |
      |                      |<---------3-----------|
      |                      |                      |
     /~/                    /~/                    /~/
      |                      |  reply_0             |
      |<---------------------|----------4-----------|
      |                      |                      |
     /~/                    /~/                    /~/
      |   msg_n              |                      |
      |----------------------|----------5---------->|
      |                      |  reply_n             |
      |<---------------------|----------6-----------|
      |                      |                      |
     /~/                    /~/                    /~/
      |   thread_terminate   |  thread_unbind       |
      |----------7---------->|----------8---------->|
                             |                      |


0. The server signals that it wants to use thread binding by sending

   task_require_bind (mach_task_self (), port)

1. A client thread wants to send a message to the server.  Currently,
no server thread is bound to this client thread.  Mach detects that,
and modifies the message to indicate that a binding is requested.

2. If this is the last idle server thread, a new one is spawned.

3. The server thread acknowledges the binding somehow.  Maybe this
isn't even necessary.

4. The server thread answers.

5., 6. Client and server communicate as usual.

7. If the client thread terminates,

8. Mach unbinds the server thread.

[Maybe: Mach can opportunistically (8. without 7.) unbind threads to
        free resources.]


This gives us a relation between client thread and server thread.
This is easily combined with some kind of per-task (thread?) resource
ledger, and bound threads using the ledger of the client task
(thread?).

It restricts the client to synchronous IPC (there is only one server
thread answering requests for one client thread), solving the DOS
issue.

It seems feasible to implement, requiring changes only to GNU Mach,
libports, rpctrace.

[*cough*, I thought that once before...]

It can be incrementally implemented on a per port/portset basis.  A
smooth upgrade path is possible (i.e. new servers on old kernel, old
servers on new kernel).


Wdyt? WdIm? Discuss!
Justus

signature.asc
Description: PGP signature