Hi,
When I go through the IPC code, I have some questions about dqr handler. In the remote_ipc_send function within the thread-ipc.cpp file, I find a comment
" // trigger remote_ipc_receiver_ready path, because we may need to grab locks // and this is forbidden in a DRQ handler. So transfer the IPC in usual // thread code. However, this induces a overhead of two extra IPIs."
I have some questions about this comment.
1. Why cannot we grab locks in a DRQ handler? 2. Where do we need to grab lock? 3. Why can extra IPI solve this problem?
Thank you very much. Best, Yuxin
On Tue Jun 24, 2014 at 15:43:06 -0400, Yuxin Ren wrote:
When I go through the IPC code, I have some questions about dqr handler. In the remote_ipc_send function within the thread-ipc.cpp file, I find a comment
" // trigger remote_ipc_receiver_ready path, because we may need to grab locks // and this is forbidden in a DRQ handler. So transfer the IPC in usual // thread code. However, this induces a overhead of two extra IPIs."
I have some questions about this comment.
I'm not fluent in this part but I'll try.
- Why cannot we grab locks in a DRQ handler?
Because those handlers must not block.
- Where do we need to grab lock?
When the IPC does transfer some items processing those might require to take locks, for example, when mapping pages. Will not happen for simple data-only IPCs.
- Why can extra IPI solve this problem?
Because in this case the receiver will handle the IPC instead of the sender and the IPIs are there for telling the receiver about that.
Adam
Thank you very much. I have a further question. For simple data-only IPCs, do we still need 4 IPIs?
On Thu, Jun 26, 2014 at 4:38 PM, Adam Lackorzynski < adam@os.inf.tu-dresden.de> wrote:
On Tue Jun 24, 2014 at 15:43:06 -0400, Yuxin Ren wrote:
When I go through the IPC code, I have some questions about dqr handler. In the remote_ipc_send function within the thread-ipc.cpp file, I find a comment
" // trigger remote_ipc_receiver_ready path, because we may need to grab locks // and this is forbidden in a DRQ handler. So transfer the IPC in usual // thread code. However, this induces a overhead of two extra IPIs."
I have some questions about this comment.
I'm not fluent in this part but I'll try.
- Why cannot we grab locks in a DRQ handler?
Because those handlers must not block.
- Where do we need to grab lock?
When the IPC does transfer some items processing those might require to take locks, for example, when mapping pages. Will not happen for simple data-only IPCs.
- Why can extra IPI solve this problem?
Because in this case the receiver will handle the IPC instead of the sender and the IPIs are there for telling the receiver about that.
Adam
Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
On Fri Jun 27, 2014 at 10:21:38 -0400, Yuxin Ren wrote:
Thank you very much. I have a further question. For simple data-only IPCs, do we still need 4 IPIs?
I'm still not fluent but 4 are too many.
Adam
Hi
I found this code is pretty hard to understand. I have learned it for more than a week, but made little progress. I measured the cross core IPC cost, and from the result, it looks like there is only two IPIs, at least for simple data-only IPC. But I cannot make sure this based on the code. Could you give me more hints about this?
Thanks so much,
Best
On Tue, Jul 1, 2014 at 5:44 PM, Adam Lackorzynski <adam@os.inf.tu-dresden.de
wrote:
On Fri Jun 27, 2014 at 10:21:38 -0400, Yuxin Ren wrote:
Thank you very much. I have a further question. For simple data-only IPCs, do we still need 4 IPIs?
I'm still not fluent but 4 are too many.
Adam
Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
On Mon Jul 07, 2014 at 11:15:27 -0400, Yuxin Ren wrote:
I found this code is pretty hard to understand. I have learned it for more than a week, but made little progress. I measured the cross core IPC cost, and from the result, it looks like there is only two IPIs, at least for simple data-only IPC. But I cannot make sure this based on the code. Could you give me more hints about this?
I think you should be looking more closely at the DRQ functionality. Did you play with the logging options that are there (shift-O in jdb)? You can also add you own logs with "LOG_MSG(current(), "text");" or with some values using LOG_MSG_3VAL. You can then look at the trace in jdb via shift-T and thus follow what the code is doing.
Adam
l4-hackers@os.inf.tu-dresden.de