Hello!
On my endavor to understand the MIG magic better, I stumbled over the
following:
On Fri, Mar 08, 2002 at 01:39:49AM +0100, Marcus Brinkmann wrote:
> [...]
i386/include/mach/i386/mach_i386.defs
> +type io_port_t = MACH_MSG_TYPE_INTEGER_16;
> +type io_perm_t = mach_port_t
> +
On Sun, Mar 10, 2002 at 10:07:32PM -0500, Roland McGrath wrote:
> The question is basically whether or not you have a free
> list for fast allocation.
Ah, ok.
> > New patch, for now without a zone for iopb's, at
> > http://www.debian.org/~brinkmd/iopb-2002-03-11.patch
>
> Go ahead and put it in
Great work!
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
> Do you think the performance increase is worth the memory overhead of a
> zone, esp if you preallocate iopb's (each being 8192 bytes huge)?
What memory overhead are you talking about? The zone_t data structure is
just a few words. The question is basically whether or not you have a free
list
On Fri, Mar 08, 2002 at 07:14:46PM -0500, Roland McGrath wrote:
> The io_bitmap_* functions can be static (and get inlined), no?
Yes, done.
> You left machine_task_zone.
Uh, removed.
> Btw, you could use a zone for the iopb's instead of
> kalloc, since they are all the same size. It's not muc
The io_bitmap_* functions can be static (and get inlined), no? You left
machine_task_zone. Btw, you could use a zone for the iopb's instead of
kalloc, since they are all the same size. It's not much difference, but
maybe a wee bit faster. With the alias decl, you should not need the
#define fo
On Wed, Mar 06, 2002 at 02:58:56AM -0500, Roland McGrath wrote:
> Please add -p to your diff switches.
At one time I will learn it, sorry. I did it this time.
> For ktss, don't use a weak alias, use a strong one.
Done (I needed to put "ktss" in parenthesis).
> I don't see a reason to zalloc
I am just skimming the code and not thinking too deeply about it right now,
since we covered it in detail before. Just some nits off hand:
Please add -p to your diff switches.
For ktss, don't use a weak alias, use a strong one. You don't want some
other base_tss definition to possibly take pre
On Thu, Feb 28, 2002 at 04:45:21PM -0800, Thomas Bushnell, BSG wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>
> > I haven't considered alternatives, like suspending threads. I am not sure
> > if that would work. I guess that if you do it within the I/O bitmap lock,
> > it could be safe
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> I haven't considered alternatives, like suspending threads. I am not sure
> if that would work. I guess that if you do it within the I/O bitmap lock,
> it could be safe, although it seems to me that it is potentially much
> slower than the other ap
On Thu, Feb 28, 2002 at 04:30:12PM -0800, Thomas Bushnell, BSG wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>
> > Design flaw: Changes don't propagate immediately to other threads in
> > the same task running on another processor. This applies to enable as
> > well as disable operations
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Design flaw: Changes don't propagate immediately to other threads in
> the same task running on another processor. This applies to enable as
> well as disable operations! Espen Skoglund pointed out that we only
> need to propagate disable operation
Hi,
here is the latest version of the patch. It should actually be quite
close to a final version. Roland, if there is anything I haven't
addressed please let me know. I have tested it for functionality,
but I have not done stress testing (we will certainly get to that).
Design flaw: Changes
13 matches
Mail list logo
