| |||||||||||||
The source of the e1000e corruption bugThe source of the e1000e corruption bugPosted Oct 24, 2008 9:45 UTC (Fri) by NAR (subscriber, #1313)Parent article: The source of the e1000e corruption bug
But the kernel makes a lot of function calls, so even this version will have a noticeable overhead; Exactly how noticable? I was wondering, because the erlang VM also has a similar trace capability that can be turned on and off at runtime. I don't know how it's implemented, but I doubt there's NOOP-ing of instructions involved - still, it is used in fairly performance-critical applications. I just can't help the feeling that NOOP-ing was done because modifying code on-the-fly is sexy, not because it's that much faster.
(Log in to post comments)
The source of the e1000e corruption bug Posted Oct 24, 2008 12:42 UTC (Fri) by nevets (subscriber, #11875) [Link] Our first version was not to replace the calls by nops, but by jmps (jmp three bytes forward, two bytes for the jmp call, three nops to skip). This itself showed a 1 or 2% overhead. Not much, but enough to make it not acceptable.Now adding a branch to the equation will definitely bring the overhead up. Remember, this is called at every function call inside the kernel.
|
|||||||||||||