Re: You could do worse than Mach ports

[Terry Lambert <tlambert2@xxxxxxxxxxxxxx>]

Matthew Dillon wrote:
>     Even something like cryptfs can conceivably, if a crypto chip is
>     present, use DMA to directly access the data without it having to be
>     mapped.  And if it isn't, so what?  You wind up mapping the data and
>     take the performance hit.  Just because you might have to do it for
>     some subsystems doesn't mean you should go and burden *ALL* the
>     subsystems with that kind of overhead.

Cache coherency.  It's a big problem.  Given the design information
disclosed so far, the assumptions tend to make me believe that the
coherency model would not work for NUMA, IA64 (more than 4 CPU),
SPARC, PPC, and a number of other platforms.

That's not a problem, if you want to limit yourself to 32 bit Intel,
but it becomes one, if you want to permit porting.


>     Also, data mapping and range
>     locking are two entirely separate beasts.  You do not always need to
>     range lock something you are mapping, and you do not always need to
>     map something you are range-locking.

I don't think I suggested locking...

>     So integrating those functions into
>     the core messaging system just adds more conditionals the critical path,
>     making the core messaging system less efficient without any peformance
>     improvements to show for it.

Actually, there's a rather nice model, where you register the
event you are interested in, unlock, and then block waiting for
the interesting event.  By decoupling this, you protect yourself
completely against races.  In general, you can get by with having
an interest in only a single event, meaning that you don't have
to implement chaining, stacking, etc., for the notification or
registration of interest: you just spam the old values with the
new to indicate interest, and the block is a clock on the address
of an object (not unlike tsleep).


>     It is important to keep interface APIs as simple as possible.  For example,
>     the core messaging API does not require message sizes to be specified or
>     memory objects to be registered.  That isn't its job.

Again, I wasn't suggesting this.  Peter's statements in his
first paragraph are more on the nose with what I was interested
in communicating.


>     But the device driver itself would work the same either way, and
>     the best case winds up being the most optimal case.  That is what
>     is important.  If I burden the messaging API with message sizes,
>     registered memory objects, data space conversions, data mappings, and
>     all sorts of insundry other mach-like stuff I impose a severe burden
>     on the 'best' case message passing situation which unnecessarily slows
>     down the system and makes the messaging API far less useful because it
>     would no longer be a light weight mechanism and thus no longer be
>     suitable for light weight operations.

I would think that, if you were in the same protection domain,
the costs would go down no matter what.  One of the big wins
of the Chorus microkernel (which is more the direction I was
trying to head) is that it eliminated the protection domain
crossing entirely for "trusted" subsystems.

This would still let you run (at the inflated cost of the
protection domain crossings) in user space, but take *away*
cost, beyond what you seem to be planning, for things like
pagers, etc., operating in kernel space.

One thing you should *not*( do is follow Mach down the road
of implementations like external pagers (*shudder*).

-- Terry