Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Sep 2010 13:10:03 GMT
From:      Alexander Motin <mav@FreeBSD.org>
To:        freebsd-acpi@FreeBSD.org
Subject:   Re: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new features not supported
Message-ID:  <201009231310.o8NDA3rV041765@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/135447; it has been noted by GNATS.

From: Alexander Motin <mav@FreeBSD.org>
To: Dmitry Kubov <dk@garant.ru>
Cc: Andriy Gapon <avg@FreeBSD.org>, jh@FreeBSD.org, 
 bug-followup <bug-followup@FreeBSD.org>
Subject: Re: i386/135447: [i386] [request] Intel Core i7 and Nehalem-EP new
 features not supported
Date: Thu, 23 Sep 2010 16:01:09 +0300

 Dmitry Kubov wrote:
 > 
 >> This CPU has only 266MHz TurboBoost speedup. And some part of it
 >> (probably half) could be enabled all the time. This benefit still could
 >> be overweighted by C-states latencies penalty. It could be interesting
 >> to test some other workloads, like compilation with different number of
 >> threads.
 >>
 > 
 > Actually tested 8.1-RELEASE with both TurboBoost options in BIOS:
 > 
 > TurboBoost OFF
 > Ubench Single CPU:   451935 (0.40s)
 > Ubench Single CPU:   450927 (0.40s)
 > Ubench Single CPU:   450486 (0.40s)
 > 
 > TurboBoost ON
 > Ubench Single CPU:   450890 (0.40s)
 > Ubench Single CPU:   450890 (0.40s)
 > Ubench Single CPU:   449926 (0.40s)
 > 
 > C-states latencies penalty is reasonable idea. But looks like P0-state
 > not activated at all.
 
 Try to kill powerd and manually set highest CPU frequency. 0.40s test
 time looks a bit suspicious, as powerd may just not react in time to set
 P0 state.
 
 > What about too high %% for C3 state during heavy load:
 > dev.cpu.0.cx_usage: 0.17% 0.06% 99.75% last 7560us
 
 It's not really strange. These numbers count number of enters into each
 state. So when CPU is completely bust - they won't be updated. Main case
 when C1 state should be actively used/counted is loads with high
 interrupt rate or heavy context switching, such as disk I/O or network load.
 
 >> Disk performance fix is reasonable. Some recent improvements in
 >> 9-CURRENT should improve it even more. What's about ubench - try some
 >> different load.
 >>
 > Can you suggest other CPU only benchmark?
 > 
 > make -j 16 buildworld
 > can't load all cores, can't see less than 11% idle
 
 I think it's not the main goal to completely load all CPUs. But this
 test is realistic and has really usable result.
 
 -- 
 Alexander Motin



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