bug-hurd
[Top][All Lists]
Advanced

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

Re: Build times of hurd and glibc for different versions of gnumach, hu


From: Samuel Thibault
Subject: Re: Build times of hurd and glibc for different versions of gnumach, hurd and glibc
Date: Tue, 19 Apr 2016 12:18:01 +0200
User-agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)

Svante Signell, on Tue 19 Apr 2016 12:08:07 +0200, wrote:
> > Looking at ps -feMj, it seems that it's ext2fs which consumes much more
> > CPU time, thus increasing overall wallclock time. It'd probably be
> > interesting to profile ext2fs, to see what takes longer. Perhaps it's
> > the hash table which is less efficient since with the new page cache
> > policy there are much more cached files?
> 
> Are you preparing ext2fs for profiling? .../pkg-glibc/glibc: hurd-i386: Fix
> recording profiling from ext2fs

Yes. I just got the results, attached here.

Both files refer to a build of glibc, which took about 10 minutes more
with the new policy than with the old policy (consistent measure among
several builds)

The ps output at the beginning of the file shows that the ext2fs process
which was storing files for the build indeed took something like 10
minutes more.

Then the flat profile is interesting (note that fields such as "self
seconds" seem to have a bug: they should be 100x bigger, most probably
yet another issue with the announcement of the kernel clock rate):

- hurd_ihash_add takes most of the time with the old policy, less so
  with the new policy, but still concerning.
- mutexes take a lot of time. Gsync will be helpful here :)
- the "self seconds" field is actually mostly the same between the old
  and the new policy.

The last remark makes me think that the performance issue being raised
is in the kernel, not in userland.

Samuel

Attachment: prof-oldpolicy
Description: Text document

Attachment: prof-newpolicy-sorted
Description: Text document


reply via email to

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