From: linas@austin.ibm.com (Linas Vepstas)
To: Nathan Lynch <ntl@pobox.com>
Cc: linuxppc-dev@ozlabs.org, anton@au1.ibm.com,
Srinivasa Ds <srinivasa@in.ibm.com>,
paulus@samba.org, ego@in.ibm.com
Subject: Re: [RFC] [PATCH] cpu hotplug on power based systems.
Date: Thu, 16 Nov 2006 15:02:03 -0600 [thread overview]
Message-ID: <20061116210203.GC23600@austin.ibm.com> (raw)
In-Reply-To: <20061116154051.GB2008@localdomain>
On Thu, Nov 16, 2006 at 09:40:51AM -0600, Nathan Lynch wrote:
> Srinivasa Ds wrote:
> >
> > Linux kernel uses some of the rtas token to perform cpu hotplug on power
> > systems. Some of the systems may not provide all the rtas services,which
> > are required to perform cpu hotplug. Like for example
> > 1) JS20 doesn't provide "stop-self" token and cpu hotplug operations
> > on these systems causes system to crash.
> > 2) some of the p630 systems doesn't provide "query-cpu-stopped-state"
> > token and we are not sure of whether cpu is under stopped state or not
> > or stop-self is still in progress .
>
> Neither of these systems (well, the p630 in "SMP" mode) have
> hypervisors so their firmwares don't provide the rtas primitives for
> CPU offline.
>
> > So we can't take decision on whether cpu really has gone offline or not.
> >
> > So we need to make sure that all required rtas tokens for cpu hotplug
> > are available during rtas initialization phase and to disable cpu
> > hotplug if they are not available.
> > I have developed the patch which does the above thing. Please let me
> > know your comments on this.
>
> Would be better to either a) inhibit creation of the sysfs 'online'
> cpu attributes (I thought we used to handle this correctly on these
> systems) or b) use the generic cpu hotplug operations which have no
> dependency on RTAS.
Yeah, good point. It seemes cleaner to do this, than to add a new
state ("per disabled") that adds complexity to the generic kernel code.
Perhaps we could set this up so that, if rtas "stop-self" is not
defined, then generic_cpu_die() is installed instead of pseries_cpu_die()?
--linas
next prev parent reply other threads:[~2006-11-16 21:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-16 14:39 [RFC] [PATCH] cpu hotplug on power based systems Srinivasa Ds
2006-11-16 15:40 ` Nathan Lynch
2006-11-16 21:02 ` Linas Vepstas [this message]
2006-11-17 3:36 ` [PATCH] Reorganise and then fixup the pseries cpu hotplug code Michael Ellerman
2006-11-17 3:59 ` Michael Ellerman
2006-11-17 4:31 ` Stephen Rothwell
2006-11-17 4:44 ` Michael Ellerman
2006-11-17 5:02 ` Stephen Rothwell
2006-11-17 18:11 ` Linas Vepstas
2006-11-20 0:44 ` Michael Ellerman
2006-11-17 18:04 ` Linas Vepstas
2006-11-20 1:08 ` Michael Ellerman
2006-11-20 4:22 ` jschopp
2006-11-20 5:59 ` Michael Ellerman
2006-11-21 16:43 ` Nathan Lynch
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=20061116210203.GC23600@austin.ibm.com \
--to=linas@austin.ibm.com \
--cc=anton@au1.ibm.com \
--cc=ego@in.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=ntl@pobox.com \
--cc=paulus@samba.org \
--cc=srinivasa@in.ibm.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 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.