Questions about sel4bench IPC statistic in the website
Hi, Your website(https://sel4.systems/About/Performance/home.pml) lists the IPC benchmark result, and I wonder is the x64 result for both fastpath, or both slowpath, or one fastpath and the other slowpath? According to the evaluation of my own on x64 kabylake, the fastpath client->server takes about 600 cycles, and slow path client->serve takes over 1100 cycles. But the website data is 1465 and 780, but it does not show whether it is fastpath or slow path. It looks like that the website data has client->server goes into slowpath(maybe because of lower priority), and the server->client goes into fastpath. Is it so? Thanks, Zihan
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'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. Note that the numbers are very sensitive to compiler version kernel configuration (especially on x86 if the meldown mitigations are enabled). Cheers, Anna. ________________________________________ From: Devel <devel-bounces@sel4.systems> on behalf of Zihan Yang <whois.zihan.yang@gmail.com> Sent: Tuesday, 7 August 2018 5:39 PM To: devel@sel4.systems Subject: [seL4] Questions about sel4bench IPC statistic in the website Hi, Your website(https://sel4.systems/About/Performance/home.pml) lists the IPC benchmark result, and I wonder is the x64 result for both fastpath, or both slowpath, or one fastpath and the other slowpath? According to the evaluation of my own on x64 kabylake, the fastpath client->server takes about 600 cycles, and slow path client->serve takes over 1100 cycles. But the website data is 1465 and 780, but it does not show whether it is fastpath or slow path. It looks like that the website data has client->server goes into slowpath(maybe because of lower priority), and the server->client goes into fastpath. Is it so? Thanks, Zihan _______________________________________________ Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
Hi Anna, <Anna.Lyons@data61.csiro.au> 于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? Thanks! Zihan
Zihan Yang <whois.zihan.yang@gmail.com> 于2018年8月10日周五 上午10:11写道：
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
participants (2)
-
Anna.Lyons＠data61.csiro.au -
Zihan Yang