Messages in this thread | | | Subject | Re: [PATCH] printk: robustify printk | From | Peter Zijlstra <> | Date | Mon, 11 Aug 2008 13:22:06 +0200 |
| |
On Mon, 2008-08-11 at 13:03 +0200, Andi Kleen wrote: > 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.
> 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.
> 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.
| |