From: Stas Sergeev <stssppnn@yahoo.com>
To: "Jos Hulzink" <josh@stack.nl>
Cc: linux-kernel@vger.kernel.org,
"Denis Vlasenko" <vda@port.imtp.ilyichevsk.odessa.ua>
Subject: Re: Larger IO bitmap?
Date: Sun, 03 Nov 2002 01:47:07 +0300 [thread overview]
Message-ID: <3DC455EB.8010803@yahoo.com> (raw)
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?
next reply other threads:[~2002-11-02 22:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-02 22:47 Stas Sergeev [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-11-02 23:56 Larger IO bitmap? Stas Sergeev
2002-11-02 18:21 Stas Sergeev
2002-11-02 21:48 ` Jos Hulzink
2002-11-02 23:19 ` Benjamin LaHaise
2002-11-03 1:42 ` Denis Vlasenko
2002-11-02 23:38 ` Denis Vlasenko
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=3DC455EB.8010803@yahoo.com \
--to=stssppnn@yahoo.com \
--cc=josh@stack.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=vda@port.imtp.ilyichevsk.odessa.ua \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.