linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brent Casavant <bcasavan@sgi.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org,
	jes@sgi.com, tony.luck@intel.com
Subject: Re: [PATCH] SN2 user-MMIO CPU migration
Date: Fri, 20 Jan 2006 14:01:24 -0600 (CST)	[thread overview]
Message-ID: <20060120134424.E91550@chenjesu.americas.sgi.com> (raw)
In-Reply-To: <200601200936.21111.jbarnes@virtuousgeek.org>

On Fri, 20 Jan 2006, Jesse Barnes wrote:

> Of course, the other option is just to require tasks that do MMIO 
> accesses from userspace to be pinned to particular CPU or node. :)

One idea I had was to add a counter into the mm struct that gets
bumped if the process performs any MMIO mappings, so that only
affected processes pay the penalty.  However, the added complexity
in the drivers (e.g. handling partial unmaps, etc.) doesn't seem worth
it.  On average this code adds 800ns to the task migration path, which
is relatively infrequent and already a bit expensive (what with cold
caches and the like).

Regarding the direction Ingo sent me down, and considering what Jack
said about needing a hook for a future platform, I'm thinking of grabbing
a bit in task->thread.flags that IA64_HAS_EXTRA_STATE() could detect and
let ia64_{save,load}_extra() call new machvecs to perform this
chipset-specific context management.  It's a bit overengineered for
my particular case, but would allow Jack to plug in his work very
cleanly.

Brent

-- 
Brent Casavant                          All music is folk music.  I ain't
bcasavan@sgi.com                        never heard a horse sing a song.
Silicon Graphics, Inc.                    -- Louis Armstrong

  reply	other threads:[~2006-01-20 20:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-20  0:06 [PATCH] SN2 user-MMIO CPU migration Brent Casavant
2006-01-20  2:18 ` Jesse Barnes
2006-01-20  6:47   ` Brent Casavant
2006-01-20 17:36     ` Jesse Barnes
2006-01-20 20:01       ` Brent Casavant [this message]
2006-01-20 13:26   ` Jack Steiner
2006-01-20 17:31     ` Jesse Barnes
2006-01-20 19:00       ` Jack Steiner
2006-01-20  8:36 ` Ingo Molnar
2006-01-20 16:14   ` Brent Casavant

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=20060120134424.E91550@chenjesu.americas.sgi.com \
    --to=bcasavan@sgi.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=jes@sgi.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@intel.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;
as well as URLs for NNTP newsgroup(s).