lkml.org 
[lkml]   [2002]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Larger IO bitmap?
Date
On 2 November 2002 16:21, Stas Sergeev wrote:
> Hello.
>
> I was trying to add some VESA support to
> dosemu and found that on my Radeon7500
> card it requires an access to the ports
> from range 0x9800-0x98ff. As ioperm()
> doesn't allow to open such a ports, I've
> got a very slow graphics.
> What happens is this:
> IO attempt->GPF->return_to_dosemu->
> decode insn->change uid->change IOPL->
> do IO->change IOPL->change uid->
> back_to_DOS_execution.
> You may guess how slow it is, but if I
> say that it is as slow as the simple
> screen redraw takes up to a minute, that
> may still be a surprise:)
>
> My question is: why do we still have a
> 128-bit IO bitmap? Is it possible to have
> the full 8K IO bitmap per process under
> Linux? And if yes, then why not yet?
> (Note: I am using the latest 2.4 kernels
> and I don't know if there is something
> changed in 2.5 about that problem. If
> something is changed, then sorry for wasting
> your time).

Guess you (and I) need to read the code.
Now that we have per-CPU TSS segments,
8K per CPU would not be a big problem, but
you'll probably need to copy 8K bitmap
into TSS whenever dosemu task starts executing
on that CPU ('normal' tasks won't need large
io bitmap). That's slow but better that what you see now :)

Another question is where to keep it.
You probably need a pointer in task struct
and dynamically allocate bitmap for dosemu-like beasts...
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:30    [W:0.082 / U:0.596 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site