public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ryan Cumming <ryan@spitfire.gotdns.org>
To: "David S. Miller" <davem@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	torvalds@osdl.org, akpm@osdl.org, linux-kernel@vger.kernel.org,
	rlrevell@joe-job.com
Subject: Re: [patch] context-switching overhead in X, ioport(), 2.6.8.1
Date: Sat, 21 Aug 2004 22:42:30 -0700	[thread overview]
Message-ID: <200408212242.33562.ryan@spitfire.gotdns.org> (raw)
In-Reply-To: <20040821214632.62d58e40.davem@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]

On Saturday 21 August 2004 21:46, David S. Miller wrote:
> FWIW, I would recommend a sparse bitmap implementation for the
> ioport stuff.

The problem is that the sparse bitmap would have to be unpacked to the "dense" 
bitmap that lives in the TSS on context switch. AFAICS, that would involve 
walking the previous task's spare bitmap, clearing all the ports it had 
access to, and then walking the next task's sparse bitmap and opening access 
to its ports. I doubt this would be a big win over what Ingo says usually 
reduces to a 128 byte or less memcpy(), especially when you consider the 
added complexity.

The only big speedup I can see is in the case of only one task having anything 
set in its IO bitmap at all. I assume that most desktops running a single X 
server fall in to this degenerate case, please correct me if I'm wrong. There 
we could simply set the TSS's io_bitmap_base to IO_BITMAP_OFFSET when 
switching to the IO bitmap'ed task, and set it back to 
INVALID_IO_BITMAP_OFFSET when we context switch away. That way the entire 
thing is accomplished with a single 4-byte store per context switch until a 
second IO bitmap'ed app is started, in which case we'd have to fall back to 
memcpy()ing. Seems like too much complexity for what amounts to a 
microoptimization, though.

BTW Ingo, have you looked at changing the almost identical code in 
arch/x86-64? Or did it not get its bitmap expanded?

-Ryan

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2004-08-22  5:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-21 13:55 [patch] context-switching overhead in X, ioport(), 2.6.8.1 Ingo Molnar
2004-08-22  4:46 ` David S. Miller
2004-08-22  5:42   ` Ryan Cumming [this message]
2004-08-22  6:00     ` Lee Revell
2004-08-22  6:06       ` Ryan Cumming
     [not found] <2vEzI-Vw-17@gated-at.bofh.it>
2004-08-22 12:16 ` Andi Kleen
2004-08-22 12:00   ` Alan Cox
2004-08-22 14:23     ` Andi Kleen
2004-08-22 14:47       ` Alan Cox
2004-08-22 17:31       ` Ingo Molnar

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=200408212242.33562.ryan@spitfire.gotdns.org \
    --to=ryan@spitfire.gotdns.org \
    --cc=akpm@osdl.org \
    --cc=davem@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rlrevell@joe-job.com \
    --cc=torvalds@osdl.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