public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: David Mosberger <davidm@napali.hpl.hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [RFD] Separating struct task and the kernel stacks
Date: Fri, 10 Jun 2005 17:03:14 +0000	[thread overview]
Message-ID: <17065.51154.969389.98052@napali.hpl.hp.com> (raw)
In-Reply-To: <9712.1118384111@kao2.melbourne.sgi.com>

>>>>> On Fri, 10 Jun 2005 08:11:42 -0700 (PDT), Christoph Lameter <christoph@lameter.com> said:

  >> Switching stacks requires that struct task is copied from the
  >> original "current" to the MCA/INIT stack, then change current to
  >> point to the new stack.  Even that is not enough, there are still
  >> places that are using the old value of "current".  The main
  >> problem is the scheduler, it tracks tasks by the address of their
  >> struct task, not by the kernel stack address.  When debugging an
  >> MCA/INIT, the mismatch between the new value of current and the
  >> old task addresses in various structures can lead to some very
  >> confusing results.  The kernel is not designed to have struct
  >> task move around on the fly.

  Christoph> Could you just move the stack? Put a pointer to the stack
  Christoph> in task_info. By default this is pointing to the stack in
  Christoph> task_info. If you have to switch point it elsewhere.

Perhaps a more fruitful approach might be to treat the MCA as its own
task.  MCA are very special anyhow: they can happen at any time, even
when the kernel is supposedly non-preemptible.  Thus, running any
standard kernel code which acquires locks etc is rather dangerous.  If
you're going to do major surgery, this really needs to be thought
through first --- otherwise, we're just going to discover all the
little nasty issues piecemeal and that would be extremely painful and
cause a lot of extra work.

Also, let's be clear that we are NOT going to (de-)optimize the normal
Linux kernel based on the needs of MCA.  Proper MCA support is
important, but that needs to be accomplished without compromising the
efficiency of the normal kernel (which is where 99.99% of the time is
spent). My sense is that the MCA subsystem may have to be almost
stand-alone in order to really work reliably.

	--david

  parent reply	other threads:[~2005-06-10 17:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-10  6:15 [RFD] Separating struct task and the kernel stacks Keith Owens
2005-06-10 15:11 ` Christoph Lameter
2005-06-10 16:54 ` David Mosberger
2005-06-10 17:03 ` David Mosberger [this message]
2005-06-10 17:13 ` Matthew Wilcox
2005-06-10 17:20 ` David Mosberger
2005-06-11  4:08 ` Keith Owens

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=17065.51154.969389.98052@napali.hpl.hp.com \
    --to=davidm@napali.hpl.hp.com \
    --cc=linux-ia64@vger.kernel.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