[lkml]   [2000]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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):

"xchgb %b0,%1"
"cmp $1, ..."
"jz ..."

Note that the jump is not taken, so it is one cycle.

"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 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.052 / U:19.924 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site