Re: [PATCH #2] console lock grabbed too early in printk...

From: Jeff Garzik (jgarzik@mandrakesoft.mandrakesoft.com)
Date: Sat Jul 01 2000 - 21:54:36 EST

On Sat, 1 Jul 2000, Chris Lattner wrote:
> 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! :)

I didn't mean to imply that the technique should be applied more
generally. printk is a very special case. My solution was proposed
partially because:

I'm not even sure that kmalloc during printk is possible, since
printk might be called during kernel init, before all the kmem caches
are created. (have no kernel tree here to check this, alas)

        Jeff

-
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