Jump label reworked
There were a number of complaints about the initial jump label implementation, including the fact that it was somewhat awkward to use. In response, a reworked version has been posted which changes the interface considerably. One starts by declaring a "jump key":
#include <linux/jump_label.h> struct jump_label_key my_key;
Enabling and disabling the key is a simple matter of calling:
jump_label_inc(struct jump_label_key *key); jump_label_dec(struct jump_label_key *key);
And using the key to control the execution of rarely-needed code becomes:
if (static_branch(&my_key)) { /* Unlikely stuff happens here */ }
In the absence of full jump label support, a jump key is represented by an atomic_t value. jump_label_inc() becomes atomic_inc(), jump_label_dec() becomes atomic_dec(), and static_branch() is implemented with atomic_read(). If jump label is configured into the kernel, enabling and disabling a jump key become heavier operations, while static_branch() becomes nearly free. For the intended use cases for jump labels, that is a worthwhile tradeoff.
As of this writing, these changes have not been merged for 2.6.39. There
is always a possibility that they could be pulled in before -rc2, but
chances are that, at this point, the new jump label will have to jump into
2.6.40.
Index entries for this article | |
---|---|
Kernel | Jump label |
Posted Mar 31, 2011 0:46 UTC (Thu)
by nevets (subscriber, #11875)
[Link]
Posted Mar 31, 2011 13:25 UTC (Thu)
by jwessel (guest, #63702)
[Link]
At the point in time this is merged it opens the door for fixing a long standing problem with the kernel debugger which you can only change today at kernel compilation time. The problem is that of keeping the debugger out of any kind of hot or default path while not in use.
The prime example on x86 is in the trap code. To avoid the possibility of recursive faults in any notification code, all traps need to pass through the kernel debug core first. Today you turn on CONFIG_KGDB_LOW_LEVEL_TRAP or you could choose to "use the debugger _very_ carefully". The jump label interface would allow us to easily turn this behavior on and off based on if an end user turn on the kernel debugger at runtime.
If you take this a step further it might also be plausible to solve the age old problem of who gets called first when killing a system, kexec or the debugger because you cannot use a notifier in the hard fail path for reliability issues. Today you change the oops handler, or unconfigure kexec if you want the debugger (kgdb or kdb) to get called first.
Posted Mar 1, 2012 10:14 UTC (Thu)
by razb (guest, #43424)
[Link]
How do the callbacks are implemented ?
Jump label reworked
Jump label reworked
Question: where is cyg_profile ?