phase of the code. Does this have to be the case or is this just a
receive.. If we switch to B , and the code reaches Bs receive phase,
data . Is the reason to do only policy based ? Can we have an IPC
( due to code bloat on the IPC path ) could be an issue. So how does
I understand that this is against the IPC behavior policies. But part
> Suresh Iyer wrote:
>> Hello Sergio
>
> Hello Suresh,
>
>>
>> This is Suresh Iyer , a grad student at UC Santa cruz. I am exploring
>> alternative scheduling ideas using temporal partitioning for L4 and
>> part of this requires modifying IPC behavior .
>
> Nice to meet you. Cool project.
>
>>
>> I had a a couple of questions on L4 ipc behaviour. I have read
>> your paper on scheduling and microkernels. I tried to post to this
>> to OKL4 list but that doesn't seem to be going through and was
>> wondering whether you could answer this for me
>
> OK, here is my answer, but with your authorisation, I would suggest to
> CC: this email exchange to the OKL4 mailing list, so that others can
> contribute with their views.
>
>
>> In the IPC implementation for l4 embedded , i see that the data is
>> transferred only( ie transfer_messsge called ) only during a send
>> phase of the code. Does this have to be the case or is this just a
>> policy decision ?
>
> Copying the message in the send path is just how the L4 IPC path was
> implemented in Pistachio, on which L4-embedded was derived from at the time.
>
> OKL4, the commercial version of L4 done by Open Kernel Labs, evolved
> significantly beyond (NICTA's) L4-embedded, which I reckon should be
> considered for most for purposes obsolete.
>
>
>> In other words, lets assume A is sending to B and B is not ready to
>> receive.. If we switch to B , and the code reaches Bs receive phase,
>> cant B transfer the data from As utcb to Bs utcb by calling
>> transfer_message of L4ka ? or do we have to switch back to A to make
>> the transfer message happen ?
>
> Without looking at the code, and speaking on top of my head, one
> advantage (note! this is not necessarily "the real reason") in simply
> switch back to A and let the copy happen in its context is the following
> one.
>
> Once the copy is done, in a Send()-only scenario, thread A "used" to
> continue to run unless B had an higher priority. This was a IPC
> scheduling policy in Pistachio.
>
> If you want to do the copy in the receive path, for consistency it
> should preserve this scheduling behavior. This would require to mirror
> the policy --- i.e., add more code in the receive sub-path --- which
> lets continue B iff it had strictly higher priority than A.
>
> More code -> larger cache footprint -> less performance.
>
> There will be many other reasons to not do the copy in the receive path,
> and I am sure that OKL engineers can help more than an academic
> researcher like me, as they can discuss the pros and cons of
> implementation choices from the perspective of significant industrial
> deployments.
>
> Moreover, I believe the OKL4 removed all the policies in the IPC path
> and elsewhere in the kernel. Scheduling decisions are now centralised,
> and strictly follow thread's priorities, to enable classic real-time OS
> behavior. Again, OKL people are the one to ask to!
>
>
>> The L4 embedded code seems to be switching to the sender to transfer
>> data . Is the reason to do only policy based ? Can we have an IPC
>
> It is not a policy. It is just to not duplicate code (and keep policies
> coherent).
>
>> mechanism in which the receiver doesnt switch to the sender , but
>> copies the data from sender to receiver ?
>
> It is possible, but it can have drawbacks.
>
>>
>> Another question on L4 embedded : Since there is no long IPC, is it
>> possible to send data like structs could be sent across threads
>> using L4 map item ?
>
> Just use shared memory.
>
>>
>> I would really appreciate an answer. Thanks so much !!
>>
>> suresh
>
> You are welcome. But I suggest to post in the official Open Kernel Labs
> mailing list. OKL people are the definitive reference for L4 in general,
> and OKL4 in particular.
>
> Sergio
>
>
> --
>
> Dr. Sergio Ruocco Research Fellow
http://www.disco.unimib.it/ruocco> mailto:
[hidden email] /
[hidden email] NOMADIS Lab
> phone: +39-02-6448-7914 Mobile, embedded real-time systems
> skype: 'sergioruocco' Dip. di Informatica, Sistemistica e COmunicazione
> Building U14, room 1003 Universitą degli Studi di Milano-Bicocca, Italy
>
> W La ricerca
http://video.google.com/videoplay?docid=-6518779854944519929>
> Your manuscript is both good and original; but the part that is good is
> not original, and the part that is original is not good.
> Samuel Johnson
>
>
