Changing SysRq - show registers handling

Hi,

Currently SysRq "show registers" command dumps registers and the call trace from keyboard interrupt context when SysRq-P. For that struct pt_regs * has to be dragged throughout entire input and USB systems. Other than passing this pointer to SysRq handler these systems has no interest in it, it is completely foreign piece of data for them and I would like to get rid of it.

I am suggesting slightly changing semantics of SysRq-P handling - instread of dumping registers and call trace immediately it will simply post a request for this information to be dumped. When next HW interrupt arrives and is handled, before running softirqs then current stack trace will be printed. This approach adds small overhead to the HW interrupt handling routine as the condition has to be checked with every interrupt but I expect it to be negligible as it is only check and conditional jump that is almost never taken. The code should be hot in cache so branch prediction should work just fine.

The patch below implements proposed changes in SysRq handler and adds necessary changes to do_IRQ() on i386. If it is agreed upon I will adjust other arches.

Please let me know what you think.

Quoted 8 lines · Dmitry Torokhov

Hi,

Currently SysRq "show registers" command dumps registers and the call trace from keyboard interrupt context when SysRq-P. For that struct pt_regs * has to be dragged throughout entire input and USB systems. Other than passing this pointer to SysRq handler these systems has no interest in it, it is completely foreign piece of data for them and I would like to get rid of it.

Quoted 9 lines

I am suggesting slightly changing semantics of SysRq-P handling - instread of dumping registers and call trace immediately it will simply post a request for this information to be dumped. When next HW interrupt arrives and is handled, before running softirqs then current stack trace will be printed. This approach adds small overhead to the HW interrupt handling routine as the condition has to be checked with every interrupt but I expect it to be negligible as it is only check and conditional jump that is almost never taken. The code should be hot in cache so branch prediction should work just fine.

What about checking the flag on return from the input interrupts? That way the overhead would be confined to code paths take the hit from passing an extra parameter.