Re: Questions

[Niels Möller]

"Martin Schaffner" <address@hidden> writes:

> Am I right in thinking that a syscall on hurd/l4 would work differently?
> If i understand correctly, it would work like this (example: reading data
> from a file):

It should be something like this:

1. Application calls read.
2. Glibc makes an ipc to the filesystem serving the file.
3. If the data is cached in the filesystem address space, and is in
   physical memory, then file system returns it to the application
   using a reply ipc.

So there are two rpc:s. Each rpc is two context switches (there are
shortcuts for rpc within the same address space, but even if all the
involved processes are run by the same user, they will still run in
separate address spaces).

The point of L4 is that ipc is highly optimized, the L4 experts will
have to correct me if I'm wrong but I think it's about 100-300 cycles,
and then thers'a also a cost of invalidation of CPU and MMU caches,
where the small l4 footprint is good at least for CPU caches (I'm not
familiar enough with memory management to say anything about MMU
state). The cost of one context sitch could well be an order of
magnitude cheaper than in linux.

In the case that you need to access the physical disk device (by
paging or by explicit filesystem-driver rpc) to get the data, I don't
think the ipc overhead matters very much.

I don't think anyone knows yet what performance an l4/hurd system can
achieve.

/Niels