Zihan Yang <[email protected]> 于2018年8月10日周五 上午10:11写道： > > Hi Anna, > > <[email protected]> 于2018年8月10日周五 上午7:20写道： > > > > > > Hi Zihan, > > > > The numbers on the benchmark are one fastpath, one slowpath (the details > > show that the length of the IPC is 10, and any messages > 4 go to the > > slowpath as they will not fit in registers). > > I see, thanks a lot. Glad to know that I get the reasonable result. I > did more warmup rounds, so the result is a little faster comapred with > the data in the website. > > > I'm going to look at getting these numbers updated with more details for > > reproducability - is there anything specific you need to know? I don't > > think we have a kabylake to test on. > > That is great, and yes I do have 2 more little questions. > > 1. Based on your real experience with seL4, what is the portion of > different kinds of IPC call in real applications? > For example, is IPC call with one fastpath one slowpath the most > common one compare with the other 2 kinds of IPC call(2 fastpath and 2 > slowpath)? What is the portion of each kind > of IPC (e.g., maybe 70%, 20%, 10%) ? > > 2. What about the one-way IPC send/recv, are they used frequently > compared with two-way IPC call?
Hi, Perhaps my questions are a little vague? I'm actually concerned with how often these kinds of IPC would appear in the real world applications, so that I can make more convincing evaluations about it. The most intuitive situation to me is that the server is an OS component with higher priority, and the client is the user program and with lower prority, so the client->server is mostly slowpath, and the reply from server->client is mostly fastpath, but I'm not sure whether it is the real case in common usage. Thanks! Zihan _______________________________________________ Devel mailing list [email protected] https://sel4.systems/lists/listinfo/devel
