Crud... I fergot the patch! :) Here we go...
-Chris
On Sat, 1 Jul 2000, Chris Lattner wrote:
>
> 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