From mboxrd@z Thu Jan 1 00:00:00 1970 From: Artem Bityutskiy Subject: Re: [PATCHv4 17/17] writeback: lessen sync_supers wakeup count Date: Mon, 31 May 2010 12:04:04 +0300 Message-ID: <1275296644.2678.122.camel@localhost> References: <1274795352-3551-1-git-send-email-dedekind1@gmail.com> <1274795352-3551-18-git-send-email-dedekind1@gmail.com> <20100527065041.GA31073@ZenIV.linux.org.uk> <20100527072240.GM22536@laptop> <1274957469.13159.20.camel@localhost> <20100527120737.GN22536@laptop> <1274973693.15516.67.camel@localhost> <20100527154435.GS22536@laptop> <1275294352.2678.102.camel@localhost> <20100531083844.GF9453@laptop> Reply-To: dedekind1@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Al Viro , LKML , Jens Axboe , linux-fsdevel@vger.kernel.org To: Nick Piggin Return-path: Received: from smtp.nokia.com ([192.100.122.233]:29803 "EHLO mgw-mx06.nokia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755943Ab0EaJGX (ORCPT ); Mon, 31 May 2010 05:06:23 -0400 In-Reply-To: <20100531083844.GF9453@laptop> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: > On Mon, May 31, 2010 at 11:25:52AM +0300, Artem Bityutskiy wrote: > > Hmm, but it looks like we cannot do that either. If we do > >=20 > > set_current_state(TASK_INTERRUPTIBLE); > > if (supers_dirty) > > bdi_arm_supers_timer(); > > schedule(); > >=20 > > and the kernel is preemptive, is it possible that we get preempted > > before we run 'bdi_arm_supers_timer()', but after we do > > 'set_current_state(TASK_INTERRUPTIBLE)'. And we will never wake up = if > > the timer armed in mark_sb_dirty() went off. > >=20 > > So it looks like this is the way to go: > >=20 > > /* > > * Disable preemption for a while to make sure we are not > > * preempted before the timer is armed. > > */ > > preempt_disable(); > > set_current_state(TASK_INTERRUPTIBLE); > > if (supers_dirty) > > bdi_arm_supers_timer(); > > preempt_enable(); > > schedule(); >=20 > This should not be required because preempt is transparent to these > task sleep/schedule APIs. >=20 > The preempt event will not clear TASK_INTERRUPTIBLE, and so the timer > wakeup will set it to TASK_RUNNING (whether or not it has called > schedule() yet and whether or not it is currently preempted). Nick, I'm sorry, but could you please elaborate: set_current_state(TASK_INTERRUPTIBLE); /*=20 * XXX: what if we are preempted here. No timer is armed. Our state is * TASK_INTERRUPTIBLE, supers_dirty is 1, so no one will ever wake us * up. Thus, we'll sleep forever. */ if (supers_dirty) bdi_arm_supers_timer(); schedule(); Not sure, but I did quick search and it looks like in preemptive kernel= , an interrupt may happen in the XXX place above, then it will call 'preempt_schedule_irq()', which sill call 'schedule()'. --=20 Best Regards, Artem Bityutskiy (=D0=90=D1=80=D1=82=D1=91=D0=BC =D0=91=D0=B8=D1=82=D1=8E= =D1=86=D0=BA=D0=B8=D0=B9) -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html