Re: Patch to Pistachio's comportement on Xfer timeouts

[Marcus Brinkmann]

At Mon, 31 Jan 2005 15:07:20 +0100,
Macrus Brinkmann wrote:
> clarity).  I also rewrote the timeout calculation code a bit to make
> it simpler and closer to the original code.  I added code for all

The whole issue is not as simple as it appeared at first.  The
troublesome case is when several pagefaults happen, and both address
spaces are involved.

For example, when first a pagefault happens in the local address
space, and then in the remote one, the timeouts are not recalculated.

It's also not entirely clear what the timeouts should be in such
cases.  If there are two timeouts, and the threads switch between
those timeouts whenever a page fault appears in the other address
space, then the max time the thread could be blocked is local+remote
timeout.  This is twice as much as expected in compatibility mode.

So, a more complete solution would have the following changes:
1. Compatibility mode is enabled by setting the local xfer timeout
values to something non-sensical (a relative timeout with e=2 and m=0
for example), and have that value as default for this UTCB register.

2. In non-compatiblity mode, it is remembered where the last pagefault
happened, and if that is in the other address space, the following
happens: the thread is removed from the wakeup queue, the current
timeout value (from the scheduler, which his now an absolute time,
maybe converted to relative time) is saved somewhere (along with the
information for which address space this was).  The old timeout for
that address space (saved in the same slot, or freshly calculated if
it never came up before) is installed and the thread is put back on
the wakeup queue.

This is a bit more complex, but quite flexible a solution.  Now I just
need to implement it ;) OTOH, we could just ignore all this and stick
with the simpler patch, which will work fine for the cases we are
interested in (client/server model with 0 and inf timeouts).

Thanks,
Marcus