On Thu, 2005-02-24 at 02:08 +0100, Marcus Brinkmann wrote:
Marcus's approach of using a zero pager timeout in server->client sends implies that the client must have means to pin its receive area (a client-defined number of page frames) for an indefinite time (there may be no contract on how fast the server replies). This can induce a very real and urgent resource denial of service problem...
The reason why I hope we will get away with it is that we are pursueing a model where every task is self-paged. Tasks get a contingent of physical memory, which is guaranteed over a long time (exact details how to negotiate that number are not determined yet)...
This would certainly look initially attractive, but let's dig in on it a little bit.
First, let us make the assumption that all string items returned from servers have a length that is known at client compile time -- the dynamically sized return strings need to be handled through other mechanisms anyway.
So: given a client's source, we can determine the longest reply string it will receive.
This number effectively sets a least bound on the number of pages of that client that must be pinned in order for the client to receive these IPC replies. Note that "pin" is a commitment to *real* memory, not virtual memory.
I believe we will shortly conclude that the design effectively sets a hard limit on the number of client processes that can be effectively run.
The physical memory server needs to be able to revoke arbitrary mappings temporarily, for example to make space for DMA buffer regions or to reorganize memory for super-page allocation. This means that the operation of the physical memory server is not transparent to the clients, and thus even to the server. (Only the kernel could make this operation transparent by an atomic copy-and-remap operation).
So, yes, the whole notion is troublesome.
I don't like having a universally trusted paging agent either, but in 15 years of thinking about this in my spare cycles I haven't come up with anything better yet. :-)
In all current L4-derived systems, the region manager (or the software that plays the equivalent functional role) is necessarily trusted completely by all of the programs that it serves.
Well, we are at least trying. If it is feasible we will see when we have implemented it...
Good luck. If my comments help to resolve what the critical collision of design objectives may be, and perhaps what degrees of design freedom might exist to resolve it, then they have perhaps achieved something useful.
It appears to me that this amounts to a special case of a more general problem: non-blocking reliable delivery of event notification. We have run into places in EROS where there is a serious need for such a mechanism, and we have been contemplating how to achieve this in Coyotos. We have now concluded that it should *not* be done in endpoints, because it is extremely desirable for endpoints to be stateless and pending events must be recorded somewhere. It is unclear at this point what alternative will emerge.
Yes. For me, such issues tend to crop up when I think about cancellation (for example due to signals). Due to lack of low-level support, we will have to do it with expensive and complicated high level constructs in the endpoints.
Since this is a separate topic, I shall reply separately with a new subject line.
shap