Re: 'git checkout' and unlink() calls (was: Re: )

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

 




On Fri, 8 May 2009, Kjetil Barvik wrote:
> 
>   So, if the numbers from strace is trustable, 0.71 seconds is used on
>   41 114 calls to lstat64().  But, look at the unlink line, where each
>   call took 259 microseconds (= 0.259 milliseconds), and all 14 379
>   calls took 3.72 seconds.

The system call times from strace are not really trustworthy. The overhead 
of tracing and in particular all the context switching back and forth 
between the tracer and the tracee means that the numbers should be taken 
with a large grain of salt. 

That said, they definitely aren't totally made up, and they tend to show 
real issues.

In this particular case, what is going on is that 'lstat()' does no IO at 
all, while 'unlink()' generally at the very least will add things to some 
journal etc, and when the journal fills up, it will force IO.

So doing 15k unlink() calls really is _much_ more expensive than doing 41k 
lstat() calls, since the latter will never force any IO at all (ok, so 
even doing just an lstat() may add atime updates etc to directories, but 
even if atime is enabled, that tends to only trigger one IO per second at 
most, and we never have to do any sync IO).

>   It should be noted that when switching branch the other way (from .25
>   to .27), the unlink() calls used less time (below 160 microseconds
>   each).

I don't think they are really "260 us each" or "160 us each". It's rather 
more likely that there are a few that are big due to forced IO, and most 
are in the couple of us case.

		Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]