Messages in this thread | | | Date | Sat, 1 Jul 2000 21:54:36 -0500 (CDT) | From | Jeff Garzik <> | Subject | Re: [PATCH #2] console lock grabbed too early in printk... |
| |
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/
| |