Hello,
I've made some further investigation about why is hurd so slow in file
access. I've tried bonnie++ on my system comparing hurd and linux (2.4.12)
performance with the following results:
(linux)
Version 1.02a ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
ratman 368M 5701 66 8347 7 3012 3 5037 59 9477 6 72.0
0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 588 74 +++++ +++ +++++ +++ 589 75 +++++ +++ 1489 75
ratman,368M,5701,66,8347,7,3012,3,5037,59,9477,6,72.0,0,16,588,74,+++++,+++,+++++,+++,589,75,+++++,+++,1489,75
(hurd)
Version 1.02a ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
hurd-developer 376M 682 2 669 0 313 1 617 1 615 0 51.6 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 93 1 2904 14 122 0 98 1 546 4 105 0
hurd-developer,376M,682,2,669,0,313,1,617,1,615,0,51.6,0,16,93,1,2904,14,122,0,98,1,546,4,105,0
I've already know the hurd is slow, but now I know how slow it is :). Btw
the test is interesting for other reason. First of all, note that file test have
a size of double of avaible RAM, and the test in the first row are random
access to this file (more detail in the readme file of bonnie++).
During the test vmstat shown that free pages are as low as few MB, and the
swap area is used for about 10-15 MB. So the vm subsystem is working
reasonably well. Instead the ext2fs translator is eating a lot of cpu power
(note: I have quite fast cpu, duron 950 Mhz). One reason can be the high
number of thread, that is more than four hundred.
So I tried to compile with profiling doing a make ext2fs/ext2fs.prof, but it
died. I solved the problem reading in the bug-hurd, and using "specs" file
posted by Marcus some time ago. Note that the problem exists in gcc 2.95 and
also 3.0.
Now the translator, launched with settrans -a, create a gmon.out when I
terminate it with settrans -g, but is often 0 length or truncated (but I
have a lot of free space), and sometimes it writes the following message:
ext2fs.prof: gmon.out: interrupted system call
The 1 million (virtual) dollar question is: how can I make the translator
write a whole gmon.out?
Thanks in advance.
--
Saluti / Regards
Diego Roversi | diegor at maganet.net
| diegor at tiscalinet.it
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
