From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Ingo Molnar <mingo@elte.hu>
Cc: Fabio Comolli <fabio.comolli@gmail.com>,
kernel list <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>
Subject: Re: [patch] sched: remove __resched_legal() and fix cond_resched_softirq()
Date: Wed, 27 Dec 2006 16:56:28 +0900 [thread overview]
Message-ID: <87ac19epqr.fsf@duaron.myhome.or.jp> (raw)
In-Reply-To: <20061226130739.GB3701@elte.hu> (Ingo Molnar's message of "Tue\, 26 Dec 2006 14\:07\:39 +0100")
Ingo Molnar <mingo@elte.hu> writes:
> * OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> wrote:
>
>> "Fabio Comolli" <fabio.comolli@gmail.com> writes:
>>
>> > Just found this in syslog. It was during normal activity, about 6
>> > minutes after resume-from-ram. I never saw this before.
>>
>> It seems someone missed to check PREEMPT_ACTIVE in __resched_legal().
>
> but PREEMPT_ACTIVE is 0x10000000, not 0x20000000.
>
>> Could you please test the following patch?
>
> no. cond_resched() is always legal in the !PREEMPT case.
>
> i found another bug and realized that the whole __resched_legal()
> approach is fundamentally wrong! The patch below fixes this.
Hmm.. but the path seems,
-> cond_resched()
-> if (__resched_legal()) /* preempt_count == 0 */
-> __cond_resched() /* preempt_count == 0x10000000 */
-> schedule()
[...]
-> cond_resched()
-> if (__resched_legal()) /* preempt_count == 0x10000000 */
-> __cond_resched() /* preempt_count == 0x20000000 */
-> schedule() /* warning */
Where is it prevented? Or warning is just wrong?
> ------------------->
> Subject: [patch] sched: remove __resched_legal() and fix cond_resched_softirq()
> From: Ingo Molnar <mingo@elte.hu>
>
> remove the __resched_legal() check: it is conceptually broken. The
> biggest problem it had is that it can mask buggy cond_resched() calls. A
> cond_resched() call is only legal if we are not in an atomic context.
> But __resched_legal() hid this fact. Same goes for cond_resched_locked()
> and cond_resched_softirq().
>
> furthermore, the __legal_resched(0) call was buggy in
> cond_resched_softirq() and caused unnecessary long softirq latencies!
>
> the fix is to preserve the only valid inhibitor to voluntary preemption:
> if the system is still booting. None of the other behavior of
> __resched_legal() made any sense.
>
> the effect of this fix should be more real bugs exposed, and shorter
> softirq latencies.
>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
> kernel/sched.c | 17 +++--------------
> 1 file changed, 3 insertions(+), 14 deletions(-)
>
> Index: linux/kernel/sched.c
> ===================================================================
> --- linux.orig/kernel/sched.c
> +++ linux/kernel/sched.c
> @@ -4617,17 +4617,6 @@ asmlinkage long sys_sched_yield(void)
> return 0;
> }
>
> -static inline int __resched_legal(int expected_preempt_count)
> -{
> -#ifdef CONFIG_PREEMPT
> - if (unlikely(preempt_count() != expected_preempt_count))
> - return 0;
> -#endif
> - if (unlikely(system_state != SYSTEM_RUNNING))
> - return 0;
> - return 1;
> -}
> -
> static void __cond_resched(void)
> {
> #ifdef CONFIG_DEBUG_SPINLOCK_SLEEP
> @@ -4647,7 +4636,7 @@ static void __cond_resched(void)
>
> int __sched cond_resched(void)
> {
> - if (need_resched() && __resched_legal(0)) {
> + if (need_resched() && system_state == SYSTEM_RUNNING) {
> __cond_resched();
> return 1;
> }
> @@ -4673,7 +4662,7 @@ int cond_resched_lock(spinlock_t *lock)
> ret = 1;
> spin_lock(lock);
> }
> - if (need_resched() && __resched_legal(1)) {
> + if (need_resched() && system_state == SYSTEM_RUNNING) {
> spin_release(&lock->dep_map, 1, _THIS_IP_);
> _raw_spin_unlock(lock);
> preempt_enable_no_resched();
> @@ -4689,7 +4678,7 @@ int __sched cond_resched_softirq(void)
> {
> BUG_ON(!in_softirq());
>
> - if (need_resched() && __resched_legal(0)) {
> + if (need_resched() && system_state == SYSTEM_RUNNING) {
> raw_local_irq_disable();
> _local_bh_enable();
> raw_local_irq_enable();
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
next prev parent reply other threads:[~2006-12-27 7:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-24 13:53 BUG: scheduling while atomic - Linux 2.6.20-rc2-ga3d89517 Fabio Comolli
2006-12-24 16:58 ` OGAWA Hirofumi
2006-12-25 19:02 ` Fabio Comolli
2006-12-26 17:15 ` Pavel Machek
2006-12-26 17:25 ` Fabio Comolli
2006-12-26 17:27 ` Randy Dunlap
2006-12-26 13:07 ` [patch] sched: remove __resched_legal() and fix cond_resched_softirq() Ingo Molnar
2006-12-27 7:56 ` OGAWA Hirofumi [this message]
2006-12-27 11:16 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ac19epqr.fsf@duaron.myhome.or.jp \
--to=hirofumi@mail.parknet.co.jp \
--cc=akpm@osdl.org \
--cc=fabio.comolli@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®