On Wed, Apr 19, 2000 at 03:04:54PM +0100, David Nowak wrote:
> That is too early. I mean this is a serious problem that people are
> interested in Hurd NOW because they could be seriously disappointed by its
> current inefficiency. Disk access is so slooooooooow! I hope it will be
> improved and I wonder why it is so inefficient. Any idea ?
Neal explained the reasons.
Apart from other solutions, it might be useful to add new RPCs for special
situations (getting a whole lot of data at once etc).
However, such decisions require very careful analysis of the code. The first
step is profiling the Hurd as it is. However, profiling doesn't work at all
currently IIRC, and thus someone could check out why exactly and how the
timer code is doing and what is needed here.
After that, profiling should be done for all involved hurd servers and the C
library.
After that, one can try to optimize the current behaviour.
BTW, not only disk access is slow. fork() is slow as well, just as an
additional example.
BTW, AFAIK, the slowness is not mandatory, eg microkernel doesn't
automatically mean slow. However, efficient microkernels have been
researched after the Hurd was started on Machs ground, so it will take osme
time to get the new ideas in the Hurd.
BTW, it can be hoped for that the Hurd will be faster on SMP and clusters
then equivalent monolitic kernels. However, this will not happen
automatically. See above.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNU http://www.gnu.org for public PGP Key
[EMAIL PROTECTED], [EMAIL PROTECTED] PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
