Okay, try two. :)
I don't think that completely redesigning the console before 2.4 goes out
is such a good idea... so here is a much smaller fix that also happens to
fix my previous oversight (yeeeouch! :).
Basically, printk needs to be locked more finely... there is no reason in
the world for the console lock to protect "buf" in addition to all the
console stuff... so this patch adds protection to buf, moves buf into
printk (as a static array), AND allows _SAFE_ recursion by kmalloc'ing a
new buffer if "buf" is in use.
This should reduce some console latency by making the console lock unheld
for the vsprintf but held for the real console stuff... This patch keeps
the common case nearly identical in performance: it only does a kmalloc
during the extremely unlikely cases that are not handled now... [okay, I
guess deadlock is "handling" it... but... :]
Personally, I didn't like the idea of having one "buf" per proc, because
it doesn't fix the recursion problem, it expands the needed data space
(albeit not by much), and (if that approach were to be allied more
generally) would bloat the kernel by a lot. The one thing it had going
for it was the fact that you could be vsprintf'ing in parrellel! :)
Anyways, let me know if I did something stupid again. :)
-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:10 EST