Messages in this thread | | | Subject | Re: [PATCH] printk: robustify printk | From | Andi Kleen <> | Date | Mon, 11 Aug 2008 13:03:39 +0200 |
| |
Ingo Molnar <mingo@elte.hu> writes:
> * Peter Zijlstra <a.p.zijlstra@chello.nl> wrote: > >> On Fri, 2008-08-08 at 21:21 +0200, Peter Zijlstra wrote: >> >> > The initial printk_tick() based implementation didn't suffer this >> > problem, should we revert to that scheme? >> >> Just in case people care.. >> >> --- >> Subject: printk: robustify printk >> >> Avoid deadlocks against rq->lock and xtime_lock by deferring the klogd >> wakeup by polling from the timer tick. > > i missed most of the discussion, but this seems like the simplest (and > hence ultimately the best) approach to me.
The problem is that it means any printk data output that is more than DMESG-BUFFER-SIZE bytes during one clock tick is going to lose data. It loses the natural adaption to higher printk rates that you got previously.
Now we could say that for debugging etc. people should switch to other mechanisms like relayfs, but I would still worry about some corner cases where losing printk data that wasn't lost before could be a severe regression (e.g. consider firewall log messages or similar)
Essentially it makes printk (much?) less reliable than it was before in the general case. Not sure that's a good thing. So the patch title is definitely misleading.
As Linus pointed out earlier we've survived with this restriction (not doing printk in the scheduler) for a long time, so is there really a that pressing need to change that?
> Coupling printk with RCU, albeit elegant, does not seem like the right > choice to me in this specific case: printk as an essential debug > mechanism should be as decoupled as possible.
RCU coupling has actually the same problem.
-Andi
| |