From: Pavel Machek <pavel@ucw.cz>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
a.p.zijlstra@chello.nl, oleg@redhat.com,
avorontsov@ru.mvista.com, mingo@elte.hu,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH/RFC] sched: Remove SYSTEM_RUNNING checks from cond_resched*()
Date: Fri, 10 Jul 2009 01:20:21 +0200 [thread overview]
Message-ID: <20090709232021.GD1469@ucw.cz> (raw)
In-Reply-To: <20090708141024.f8b581c5.akpm@linux-foundation.org>
Hi!
> > That said, I do agree that maybe SYSTEM_RUNNING isn't the right check.
> > Testing that the scheduler is initialized may be the more correct one. I
> > think the SYSTEM_RUNNING one just comes from that being used for other
> > debug issues.
>
> Agreed. system_state is too general.
>
> If we specifically want to know whether it is safe to call schedule() then
> let's create a global boolean it_is_safe_to_call_schedule and test that,
> rather than testing something which indirectly and unreliably implies "it
> is safe to call schedule". If that boolean already exists then no-brainer.
or maybe we could embed that check into schedule(), just returning
when scheduler is not ready?
And I always wondered... system_state is not protected by any kind of
lock and is not atomic_t... Does it all work by mistake?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
prev parent reply other threads:[~2009-07-10 12:06 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-07 23:58 [PATCH/RFC] sched: Remove SYSTEM_RUNNING checks from cond_resched*() Anton Vorontsov
2009-07-08 0:50 ` Oleg Nesterov
2009-07-08 6:24 ` Peter Zijlstra
2009-07-08 12:03 ` Anton Vorontsov
2009-07-08 12:12 ` Peter Zijlstra
2009-07-08 12:55 ` Anton Vorontsov
2009-07-08 12:58 ` Peter Zijlstra
2009-07-08 20:45 ` [PATCH] sched: Make cond_resched*() available earlier Anton Vorontsov
2009-07-08 16:12 ` [PATCH/RFC] sched: Remove SYSTEM_RUNNING checks from cond_resched*() Linus Torvalds
2009-07-08 21:10 ` Andrew Morton
2009-07-08 21:33 ` Anton Vorontsov
2009-07-08 21:47 ` Andrew Morton
2009-07-08 22:20 ` [PATCH] netpoll: Fix carrier detection for drivers that are using phylib Anton Vorontsov
2009-07-09 0:01 ` Linus Torvalds
2009-07-09 3:08 ` David Miller
2009-07-09 7:56 ` Peter Zijlstra
2009-07-09 12:56 ` Matt Mackall
2009-07-09 13:26 ` Matt Mackall
2009-07-09 13:46 ` Peter Zijlstra
2009-07-09 14:18 ` Matt Mackall
2009-07-09 14:31 ` Peter Zijlstra
2009-07-09 14:43 ` Matt Mackall
2009-07-09 14:51 ` Peter Zijlstra
2009-07-09 15:06 ` Matt Mackall
2009-07-09 17:29 ` Linus Torvalds
2009-07-09 12:52 ` Matt Mackall
2009-07-09 23:20 ` Pavel Machek [this message]
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=20090709232021.GD1469@ucw.cz \
--to=pavel@ucw.cz \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=avorontsov@ru.mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oleg@redhat.com \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.