On Mon, 2008-08-11 at 13:03 +0200, Andi Kleen wrote:
quoted text
> 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)

You only loose the msgs with klogd, console still gets everything. If
firewalls are generating that much data, perhaps its time to think about
alternative ways to channel that.

quoted text
> 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.

Depends, I don't give a rats arse about klogd - I get everything through
serial onto another machine. 

quoted text
> 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?

Why not fix it if its acceptable - the deadlock is just ugly.

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/