Posted Oct 28, 2010 7:40 UTC (Thu) by tcourbon (subscriber, #60669)
Parent article: Jump label
Is there anyway to measure the actual overhead caused by the test in the current kernel ? To my naive eyes this thing looks complicated (at least from the developer point of view).
(Furthermore does the x86 architecture include x86_64 ? If not it looks, again, over complicated for a not so impressive expected result.)
Posted Oct 28, 2010 13:22 UTC (Thu) by CChittleborough (subscriber, #60775)
[Link]
With the new approach, there is very little overhead in the instrumented code: either a NOP or an unconditional branch. The overhead has been moved to compile time (setting up the table of 'jump labels') and the time at which jumps are turned on or off (by calling enable_jump_label() or disable_jump_label(), which use the table to replace the NOP with a branch or vice versa).
Trade-off
Posted Oct 28, 2010 14:50 UTC (Thu) by nix (subscriber, #2304)
[Link]
It looks more than slightly reminiscent of the PLT's lazy binding trick to me.
Trade-off
Posted Oct 30, 2010 22:05 UTC (Sat) by giraffedata (subscriber, #1954)
[Link]
Is there anyway to measure the actual overhead caused by the test in the current kernel ?
With the new approach, there is very little overhead
I believe "current kernel" refers to kernel code before the new approach.
I.e. What do we get in return for this complication?
Jump label
Posted Dec 31, 2010 17:25 UTC (Fri) by SEJeff (subscriber, #51588)
[Link]
32bit and 64bit x86 were merged together sometime ago. You must have missed the HUGE flamewar that resulted in ingo winning and the two being merged.