bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

benchmark and profiling


From: Diego Roversi
Subject: benchmark and profiling
Date: Fri, 28 Dec 2001 15:25:55 +0100
User-agent: Mutt/1.2.5i

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 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]