[prev in list] [next in list] [prev in thread] [next in thread] 

List:       eros-arch
Subject:    Re: [eros-arch] Mapped Processes
From:       Charles Landau <clandau () macslab ! com>
Date:       2003-12-28 5:54:29
[Download RAW message or body]

At 1:23 PM -0500 12/24/03, Jonathan S. Shapiro wrote:
>On Mon, 2003-12-22 at 23:55, Charles Landau wrote:
>  > This design seems likely to require some additional copying of data
>>  by the user process to and from this page. What is the performance
>>  implication?
>
>I do not believe that this is likely. There are two issues to consider:
>the receive block descriptor and the data string.
>
>* Receive Block Descriptor
>
>... the receive block has bimodal use:
>
>   Client-side: almost always accepts just a result code. This
>   CAN be done in register.
>
>   Server-side: almost always initialized at startup and left alone.

Your proposal had a single area in the page for the receive block. 
This is used by a server to receive a message from a client, and also 
to receive results from every CALL it does. Wouldn't it have to be 
initialized on every invocation?

>In practice, there are three classes of data transfers:
>
>   1. Small transfers that can be done entirely in registers. On the
>      Pentium you can get maybe two.
>
>   2. Mid-size transfers that will be done via the mapped page.
>
>   3. Large transfers.
>
>The focus of attention should be on mid-size transfers, which describes
>the majority of invocations.

You said above (and KeyKOS experience confirms) that most client-side 
invocations receive just a result code, so aren't small transfers the 
majority?

>  > For such of this data that the kernel reads, and cares about its
>>  validity (for example, the Send/receive control description), it
>>  needs to copy the data again to kernel-only memory (or registers)
>>  before validating it. Otherwise, on a multiprocessor, another
>>  processor could change the data after it is validated. This can
>>  happen on a uniprocessor too if there could be asynchronous I/O to
>>  the page.
>
>We haven't found this to be necessary, but if you don't do it the
>implementation certainly does need to take some care.

Copying to kernel-only memory isn't necessary, but either that or 
copying to kernel-only registers (i.e. reading) is necessary. The 
data must not be reread from user space between validation and use.

>  > >The real mess in the path is on the receive side, because you have to
>>  >build a temporary cross-mapping of a part of the recipient address space
>>  >within the sender address space.
>>
>>  I'm confused. You said above you are not addressing the
>>  process-to-process case. So the sender is the kernel? When the kernel
>>  runs, is the entire user address space addressable? If so, why are
>>  cross-space mappings necessary? If not, why are they not necessary in
>>  both directions?
>
>I wrote badly. I meant that I wasn't addressing the gate jump case. Even
>for a kernel key invocation, the recipient may be in a different address
>space.

That can only happen if the kernel key invocation is not a CALL, but 
a SEND or RETURN that passes a resume key that causes the result to 
be returned to a different process, right? Surely that is not a case 
that needs to be optimized!

>The need to *check* for this is costly, never mind the result.

Checking that the invocation is a CALL should be simple.
_______________________________________________
eros-arch mailing list
eros-arch@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/eros-arch
[prev in list] [next in list] [prev in thread] [next in thread]