Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 Jun 2011 15:48:38 -0700
From:      Artem Belevich <art@freebsd.org>
To:        Dan Nelson <dnelson@allantgroup.com>
Cc:        Yuri <yuri@rawbw.com>, freebsd-hackers@freebsd.org
Subject:   Re: Why user time of the process depends on machine load?
Message-ID:  <BANLkTi=ktfxiD0EWLYZOKnL2CK14oqVMFg@mail.gmail.com>
In-Reply-To: <20110615215515.GA6889@dan.emsphone.com>
References:  <4DF91458.8010508@rawbw.com> <20110615215515.GA6889@dan.emsphone.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

On Wed, Jun 15, 2011 at 2:55 PM, Dan Nelson <dnelson@allantgroup.com> wrote=
:
> In the last episode (Jun 15), Yuri said:
>> When I test performance of the code, I always observe dependency of CPU
>> user time on the presence of other CPU intense processes. =A0Same CPU-on=
ly
>> deterministic process that on the quiet machine completes in 220 user
>> seconds in the presence of, for example, kde rebuild would complete in
>> 261, 266 or even 379 user seconds. =A0I am talking about times shown by
>> time(1), not actual an execution time. =A0It's the same time as getrusag=
e(2)
>> returns in ru_utime field.
>>
>> Why time that process takes in user seconds depends on what other
>> processes are running?
>>
>> FreeBSD-8.2 STABLE on i7 CPU @ 9200 @ 2.67GHz.
>
> Some possible factors:
>
> o Intel Turbo Boost, which raises the clock rate of a single core if the
> =A0other cores are idle. =A0A single process on an idle system will run f=
aster.
>
> o i7 chips have a shared L3 cache across all cores, so a single process o=
n
> =A0an idle system will tend to have more of its data in cache compared to=
 a
> =A0system with multiple processes, so it spends less time waiting for slo=
wer
> =A0physical memory lookups.
>
> o Process accounting isn't exact. =A0I may be wrong, but I don't think
> =A0timestamps are taken every time a syscall is invoked and returns. =A0S=
ome
> =A0time marked as "user" may actually be "system" time, in which case you=
 may
> =A0be seeing the effect of contention in the kernel as more processes are
> =A0run.

I would add hyper-threading to the list. Once you don't have enough
real cores available to do the job, things do tend to slow down,
unless your process is heavily i/o bound. The time process spends on a
hyper-thread when it's not active still counts towards total time
consumed by the process.

--Artem

>
> You may be able to disable Turbo Boot in your BIOS, which you can use to
> determine how much of the single-process speedup is due to that.
>
> Unrelated but still interesting note on your particular CPU:
> http://www.passmark.com/forum/showthread.php?t=3D2256
>
> --
> =A0 =A0 =A0 =A0Dan Nelson
> =A0 =A0 =A0 =A0dnelson@allantgroup.com
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org=
"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTi=ktfxiD0EWLYZOKnL2CK14oqVMFg>