> 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/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:14 EST