Messages in this thread | | | Date | Mon, 3 Jul 2000 15:29:24 -0700 (PDT) | From | Chris Lattner <> | Subject | Re: [PATCH #2] console lock grabbed too early in printk... |
| |
> Chris Lattner wrote: > > But my point all along is that it only addes a spin_lock and spin_unlock > > on a very low contended lock (unless you're doing tons of printk's, in > > Phrased another way, you added a totally new lock to a very common > path...
Okay, I'll look into the overhead imposed by this lock. Assuming the lock is not held (which is the only case that matters, because otherwise, access would block on the console_lock currently), we have the following (for the x86 at least, the others are similar):
spin_lock: "xchgb %b0,%1" "cmp $1, ..." "jz ..."
Note that the jump is not taken, so it is one cycle.
spin_unlock: "movb $1,%0"
Now by my count, the xchg takes a cycle to decode, and a cycle to execute (the implicit lock). The cmp & jmp takes a cycle, the movb takes a cycle. That's five cycles (+/- 3 due to instr scheduling and stuff) added to a very UNCOMMON path.
Uncommon? Yes, according to dmesg, my fairly "thick" 2.4.0test1 kernel has printed out: $ dmesg | wc -l 93
93 printk's. This includes several: keyboard: Too many NACKs -- noisy kbd cable? Due to my keyboard switch.
Multiply that by a factor of ten to take into account any configuation reasonable, and I _STILL_ don't see an overhead impact on a stock kernel.
Now if you are talking about debug situations... where printk is actually used, I bet people would rather have a forgiving printk than a blazing fast kill-me-if-I-take-a-shortcut printk.
I may be missing something, but I really don't see the overhead involved here. printk is a debugging tool and should be treated as such.
-Chris
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |