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 --]
next prev parent 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