On Tue 29-05-12 14:54:52, Jan Kara wrote: > On Tue 29-05-12 14:38:31, Peter Zijlstra wrote: > > On Tue, 2012-05-29 at 14:34 +0200, Jan Kara wrote: > > > > > The only safe solution seems to be to create a variant of percpu counters > > > that can be used from an interrupt. Or do you have other idea Peter? > > > > > > [ 20.680186] [] _raw_spin_lock+0x3b/0x70 > > > > [ 20.680186] [] ? __percpu_counter_sum+0x17/0xc0 > > > > [ 20.680186] [] __percpu_counter_sum+0x17/0xc0 > > > > [ 20.680186] [] ? init_timer_deferrable_key+0x20/0x20 > > > > [ 20.680186] [] fprop_new_period+0x12/0x60 > > > > [ 20.680186] [] writeout_period+0x3d/0xa0 > > > > [ 20.680186] [] call_timer_fn+0x12f/0x260 > > > > [ 20.680186] [] ? init_timer_deferrable_key+0x20/0x20 > > > > Yeah, just make sure IRQs are disabled around doing that ;-) > Evil ;) But we'd need to have IRQs disabled also in each > fprop_fraction_percpu() call, and generally, if we want things clean, we'd > need to disable them in all entry points to proportion code (or at least > around all percpu calls)... OK, after some thought I was wrong and fixing fprop_new_period() is enough. Attached patch should fix the warning (and possible deadlock). Fengguang should I resend you fixed patch implementing flexible proportions or do you prefer incremental patch against your tree? Honza -- Jan Kara SUSE Labs, CR