From: Linus Torvalds <torvalds@linux-foundation.org>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Oleg Nesterov <oleg@redhat.com>,
Anton Vorontsov <avorontsov@ru.mvista.com>,
Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH/RFC] sched: Remove SYSTEM_RUNNING checks from cond_resched*()
Date: Wed, 8 Jul 2009 09:12:30 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.01.0907080907210.3210@localhost.localdomain> (raw)
In-Reply-To: <1247034263.9777.24.camel@twins>
On Wed, 8 Jul 2009, Peter Zijlstra wrote:
> On Wed, 2009-07-08 at 02:50 +0200, Oleg Nesterov wrote:
>
> > /*
> > * It is valid to assume CPU-locality during early bootup:
> > */
> > if (system_state != SYSTEM_RUNNING)
> > goto out;
> >
> > this doesn't look right, smp_init() is called before we set
> > SYSTEM_RUNNING.
>
> The thing is, there's also ton's of code that might end up calling
> cond_resched() and co before the scheduler is fully initialized. Doing
> so would indeed mess things up.
I forget what triggered me to add some of them, but we definitely had bugs
with the scheduler being called early, and having some really nasty oopses
happen early in the boot (and that early, they don't get saved, so the
reporting percentage goes down to something very low).
So I think that the patch Anton posted is probably the RightThing(tm) to
do, and in that sense I like it - but they make me very nervous. There's a
lot of "cond_resched()"s sprinkled about in helper routines, and if they
are ever called early, you're basically screwed.
> Also, by definition we'd have to call smp_init() before SYSTEM_RUNNING,
> because you simply cannot declare a system up and running when your core
> functionality isn't initialized.
Now, that part I'm not sure about.
We can consider a UP system to be running, and brining up the other CPU's
to be a matter of CPU hotplug.
It's not what we do _now_, of course. We don't force hotplug support on
people just because they want SMP, and we don't want to go through the
whole "rewrite locks" things twice etc.
> So I'd really rather preserve these checks -- I can even remember
> running into some of these things a while back, but memory isn't
> providing specific cases.
Yes. I get nervous too about the patch.
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.
Linus
next prev parent reply other threads:[~2009-07-08 16:15 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-07 23:58 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 ` Linus Torvalds [this message]
2009-07-08 21:10 ` [PATCH/RFC] sched: Remove SYSTEM_RUNNING checks from cond_resched*() 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 ` [PATCH/RFC] sched: Remove SYSTEM_RUNNING checks from cond_resched*() Pavel Machek
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=alpine.LFD.2.01.0907080907210.3210@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--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 \
/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
Powered by JetHome