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).
I think that could be an advantage also for
X. I think currently X works around the
problem by keeping IOPL==3 all the run,
but that can't work for dosemu.
I've found several discussions on that
topic, but they all ended unconclusively
(too difficult, too expensive, useless etc).
But as the last discussion I've found was
dated 1998, I think it is time to reiterate:)
Can anyone please suggest what must be done
in order to enlarge the thing? The obvious
way of increasing IO_BITMAP_SIZE constant
doesn't do the trick.
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
On 2 November 2002 19:48, Jos Hulzink wrote:
> Hi,
>
> Increasing the IO bitmap size has huge effects on your Task State
> Segment size. It sure is possible to increase that size, but be aware
> that this means you are using megabytes for your TSS's only !
We have per-CPU TSS, not per task
--
vda
Hi,
Increasing the IO bitmap size has huge effects on your Task State Segment
size. It sure is possible to increase that size, but be aware that this means
you are using megabytes for your TSS's only !
Of course, with current memory sizes, some might say "why bother", but IMHO it
is still a very good reason not to do it. The Embedded guys will sure agree
with me.
Running iopl(3) isn't that bad, as long as your code knows what it is doing...
Ioperm is only needed for virtual 8086 mode (aka DOS emulation mode) and is
nice for buggy code. (If you don't trust your own programming skills and
think you might pass wrong parameters to outb() )
You need root privileges for both iopl and ioperm requests, so that is no
argument eighter. The fact your software runs setuid root automatically means
you trust the software.
With this in mind, dosemu is the only reason why the bitmap should be
extended. (virtual 86 mode uses the bitmap to emulate io access when needed).
In my humble opinion, dosemu is not important enough to make TSS's huge
bloated things by default.
The advantage for XFree would be that it needs to call ioperm() a thousand
times instead of calling iopl() once. That sure is an advantage in my eyes...
Well... it might be an option in the kernel on x86 systems: [ ] bloat kernel
memory usage with huge TSS's, but I really thing this should not be the
default way to go.
Jos
On Saturday 02 November 2002 19: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).
>
> I think that could be an advantage also for
> X. I think currently X works around the
> problem by keeping IOPL==3 all the run,
> but that can't work for dosemu.
>
> I've found several discussions on that
> topic, but they all ended unconclusively
> (too difficult, too expensive, useless etc).
> But as the last discussion I've found was
> dated 1998, I think it is time to reiterate:)
>
> Can anyone please suggest what must be done
> in order to enlarge the thing? The obvious
> way of increasing IO_BITMAP_SIZE constant
> doesn't do the trick.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Hello.
Jos Hulzink wrote:
> Increasing the IO bitmap size has huge effects on your Task State Segment
> size. It sure is possible to increase that size, but be aware that this
> means you are using megabytes for your TSS's only !
As far as I can read the code
(not too far actually, so correct
me please), we have a per-process
IO bitmap copy, which gets copied
into a per-cpu TSS upon a task switch.
That means that you are right about the
overhead, but at the same time I see
nothing that keeps us from a dynamic
memory allocation for the per-process
copy, as soon as an ioperm() is called.
Is this possible?
> Running iopl(3) isn't that bad, as long as your code knows what it is
> doing...
> Ioperm is only needed for virtual 8086 mode (aka DOS emulation mode)
> With this in mind, dosemu is the only reason why the bitmap should be
> extended.
Well, at least I think that the VESA
driver of X also uses v86 for the video
bios invocations. It doesn't sucks as badly
as dosemu does probably because even using
vm86(), they still can keep IOPL==3, dosemu
can't. So I think that would still be an
improvement, probably not so noticeable as
it could be for dosemu, but still.
> In my humble opinion, dosemu is not important enough to make TSS's huge
> bloated things by default.
What if we treat dosemu not as a single
program, but as all that progs that can
work under it and require VESA?:)
> Well... it might be an option in the kernel on x86 systems: [ ] bloat
> kernel
> memory usage with huge TSS's, but I really thing this should not be the
> default way to go.
By any means I am not going to pollute the
memory by a useless per-process IO bitmap
copies. As we have a per-cpu TSS (thanks for
the hint, Denis), we'd have bloat only on a
per-process copies, but I wonder if it is
possible to avoid them except for the processes
that require it?
I wouldn't ask so much and just try the things
out, but for the one thing: what must be done,
besides increasing the IO_BITMAP_SIZE const of a
processor.h, in order to get the larger IO bitmap
right now? As I want to experement a bit, I
need to get it large at first, no matter how much
memory will it eat. But how can I do even that?
On Sat, Nov 02, 2002 at 10:48:11PM +0100, Jos Hulzink wrote:
> Hi,
>
> Increasing the IO bitmap size has huge effects on your Task State Segment
> size. It sure is possible to increase that size, but be aware that this means
> you are using megabytes for your TSS's only !
Keep in mind that a task's io bitmap is now lazily allocated, so by
default no memory will be allocated for it. A similar enhancement
for large vs small io bitmaps could be made by allowing the task io
bitmap to be a variable size.
-ben
Hello.
Benjamin LaHaise wrote:
>> you are using megabytes for your TSS's only !
> Keep in mind that a task's io bitmap is now lazily allocated, so by
> default no memory will be allocated for it.
Thanks, indeed browsing the 2.5 sources
at BK I see it is already done that way.
Had to upgrade before asking, as it doesn't
seem to be the case for 2.4(.19).
But then what are the reasons for the IO
bitmap to still be small at all? Are there
any reasons left?
> A similar enhancement
> for large vs small io bitmaps could be made by allowing the task io
> bitmap to be a variable size.
But is it really important?