Have you tried to disable hypertreads in the BIOS ???
It's a long shot, I know, but it might help.
On 2016-12-10 22:14, PeerCorps Trust Fund wrote:
Hi,
On both systems HAMMER was used. One small correction concerning the
2c/2t machine, both compression programs did effectively utilize that
CPU which had an idle % of 0.0. It is the bigger machine, 16c/32t
where the CPU isn't effectively maxed out. I'll continue to try and
investigate why and report back if I find anything.
On 12/10/2016 10:26 PM, Justin Sherrill wrote:
On the two DragonFly systems, was it Hammer or UFS? I would be
surprised if that made a difference, but it might?
On Sat, Dec 10, 2016 at 6:19 AM, PeerCorps Trust Fund
<[email protected]> wrote:
Hi,
I've observed that parallel compression tools such as pixz and
lbzip2 do not
make use of all of the available CPU under Dragonfly. On other OSes, it
does.
When testing on a 50 gb file, using top I've observed that CPU idle
percentages consistently hover around the 90% range for pixz and
~70% for
lbzip2. These values under FreeBSD and Linux are typically ~0.0%
idle until
compression is complete. Correspondingly, compression takes
significantly
longer under Dragonfly, so the CPU is really being under utilized in
this
case as opposed to erroneous reporting by top.
This was tested on two systems, one 16c/32t and a 2c/2t system on a
recent
master DragonFly v4.7.0.973.g8d7da-DEVELOPMENT #2: Wed Dec 7
11:44:04 EET
2016.
Has anyone else possibly observed this?
--
Mike
