Re: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode
On Thu, Sep 06, 2018 at 03:02:29AM +0300, Lev Serebryakov wrote: > Hello Benjamin, > > Thursday, September 6, 2018, 1:32:46 AM, you wrote: > > >> > I don't think you need something accurate. > >> Ok, here is results. I'm working in single-user mode. > >> > >> TL;DR "Turbo" mode make "openssl" much slower (x3.5)! > >> > >> I can not properly interpret this result. > > > You need to say more about what openssl is doing (i.e., how it was > > configured, what architecture it's on, etc.). In particular, there > > was for a time an AVX2 implementation for some primitives, that ended up > > being a net loss, since heavy use of those instructions would cause > > overheating and throttling. OpenSSL has a lot of custom assembly for these > > common primitves, with some logic to select among them both at > > configuration time and at runtime, so results such as this may or may not > > be widely transferrable. > > It is system (very fresh ALPHA4) openssl, built with default settings. > Simple single run with one thread, without AES-NI: > > openssl speed aes-256-cbc > > It is as simple as that. Okay, "system openssl" and the FreeBSD version is enough to nail down the code and configuration, and I see the processor type is in the subject line. I guess posting the CPU features bits from dmesg might save whoever tries to track down the codepaths being used some time (unless that was posted already and I missed it?). -Ben ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4
On Wed, Sep 05, 2018 at 11:15:03PM +0300, Subbsd wrote:
> On Wed, Sep 5, 2018 at 5:58 PM Allan Jude wrote:
> >
> > On 2018-09-05 10:04, Subbsd wrote:
> > > Hi,
> > >
> > > I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12
> > > to latest revision (r338466 the moment) and related to ARC.
> > >
> > > I can not say which revision was before except that the newver.sh
> > > pointed to ALPHA3.
> > >
> > > Problems are observed if you try to limit ARC. In my case:
> > >
> > > vfs.zfs.arc_max="128M"
> > >
> > > I know that this is very small. However, for two years with this there
> > > were no problems.
> > >
> > > When i send SIGINFO to process which is currently working with ZFS, i
> > > see "arc_reclaim_waiters_cv":
> > >
> > > e.g when i type:
> > >
> > > /bin/csh
> > >
> > > I have time (~5 seconds) to press several times 'ctrl+t' before csh is
> > > executed:
> > >
> > > load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.41r 0.00u 0.00s 0%
> > > 3512k
> > > load: 0.70 cmd: csh 5935 [zio->io_cv] 1.69r 0.00u 0.00s 0% 3512k
> > > load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.98r 0.00u 0.01s 0%
> > > 3512k
> > > load: 0.73 cmd: csh 5935 [arc_reclaim_waiters_cv] 2.19r 0.00u 0.01s 0%
> > > 4156k
> > >
> > > same story with find or any other commans:
> > >
> > > load: 0.34 cmd: find 5993 [zio->io_cv] 0.99r 0.00u 0.00s 0% 2676k
> > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.13r 0.00u 0.00s 0%
> > > 2676k
> > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.25r 0.00u 0.00s 0%
> > > 2680k
> > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.38r 0.00u 0.00s 0%
> > > 2684k
> > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.51r 0.00u 0.00s 0%
> > > 2704k
> > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.64r 0.00u 0.00s 0%
> > > 2716k
> > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.78r 0.00u 0.00s 0%
> > > 2760k
> > >
> > > this problem goes away after increasing vfs.zfs.arc_max
> > > ___
> > > freebsd-current@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> > >
> >
> > Previously, ZFS was not actually able to evict enough dnodes to keep
> > your arc_max under 128MB, it would have been much higher based on the
> > number of open files you had. A recent improvement from upstream ZFS
> > (r337653 and r337660) was pulled in that fixed this, so setting an
> > arc_max of 128MB is much more effective now, and that is causing the
> > side effect of "actually doing what you asked it to do", in this case,
> > what you are asking is a bit silly. If you have a working set that is
> > greater than 128MB, and you ask ZFS to use less than that, it'll have to
> > constantly try to reclaim memory to keep under that very low bar.
> >
>
> Thanks for comments. Mark was right when he pointed to r338416 (
> https://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c?r1=338416=338415=338416
> ). Commenting aggsum_value returns normal speed regardless of the rest
> of the new code from upstream.
> I would like to repeat that the speed with these two lines is not just
> slow, but _INCREDIBLY_ slow! Probably, this should be written in the
> relevant documentation for FreeBSD 12+
Could you please retest with the patch below applied, instead of
reverting r338416?
diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
index 2bc065e12509..9b039b7d4a96 100644
--- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
+++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
@@ -538,7 +538,7 @@ typedef struct arc_state {
*/
int zfs_arc_meta_prune = 1;
unsigned long zfs_arc_dnode_limit_percent = 10;
-int zfs_arc_meta_strategy = ARC_STRATEGY_META_BALANCED;
+int zfs_arc_meta_strategy = ARC_STRATEGY_META_ONLY;
int zfs_arc_meta_adjust_restarts = 4096;
/* The 6 states: */
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode
Hello Benjamin, Thursday, September 6, 2018, 1:32:46 AM, you wrote: >> > I don't think you need something accurate. >> Ok, here is results. I'm working in single-user mode. >> >> TL;DR "Turbo" mode make "openssl" much slower (x3.5)! >> >> I can not properly interpret this result. > You need to say more about what openssl is doing (i.e., how it was > configured, what architecture it's on, etc.). In particular, there > was for a time an AVX2 implementation for some primitives, that ended up > being a net loss, since heavy use of those instructions would cause > overheating and throttling. OpenSSL has a lot of custom assembly for these > common primitves, with some logic to select among them both at > configuration time and at runtime, so results such as this may or may not > be widely transferrable. It is system (very fresh ALPHA4) openssl, built with default settings. Simple single run with one thread, without AES-NI: openssl speed aes-256-cbc It is as simple as that. -- Best regards, Levmailto:l...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode
On Wed, Sep 05, 2018 at 07:27:06PM +0300, Lev Serebryakov wrote: > On 05.09.2018 17:51, Cy Schubert wrote: > > > I don't think you need something accurate. > Ok, here is results. I'm working in single-user mode. > > TL;DR "Turbo" mode make "openssl" much slower (x3.5)! > > I can not properly interpret this result. You need to say more about what openssl is doing (i.e., how it was configured, what architecture it's on, etc.). In particular, there was for a time an AVX2 implementation for some primitives, that ended up being a net loss, since heavy use of those instructions would cause overheating and throttling. OpenSSL has a lot of custom assembly for these common primitves, with some logic to select among them both at configuration time and at runtime, so results such as this may or may not be widely transferrable. -Ben ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4
On Wed, Sep 5, 2018 at 5:58 PM Allan Jude wrote: > > On 2018-09-05 10:04, Subbsd wrote: > > Hi, > > > > I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12 > > to latest revision (r338466 the moment) and related to ARC. > > > > I can not say which revision was before except that the newver.sh > > pointed to ALPHA3. > > > > Problems are observed if you try to limit ARC. In my case: > > > > vfs.zfs.arc_max="128M" > > > > I know that this is very small. However, for two years with this there > > were no problems. > > > > When i send SIGINFO to process which is currently working with ZFS, i > > see "arc_reclaim_waiters_cv": > > > > e.g when i type: > > > > /bin/csh > > > > I have time (~5 seconds) to press several times 'ctrl+t' before csh is > > executed: > > > > load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.41r 0.00u 0.00s 0% > > 3512k > > load: 0.70 cmd: csh 5935 [zio->io_cv] 1.69r 0.00u 0.00s 0% 3512k > > load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.98r 0.00u 0.01s 0% > > 3512k > > load: 0.73 cmd: csh 5935 [arc_reclaim_waiters_cv] 2.19r 0.00u 0.01s 0% > > 4156k > > > > same story with find or any other commans: > > > > load: 0.34 cmd: find 5993 [zio->io_cv] 0.99r 0.00u 0.00s 0% 2676k > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.13r 0.00u 0.00s 0% > > 2676k > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.25r 0.00u 0.00s 0% > > 2680k > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.38r 0.00u 0.00s 0% > > 2684k > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.51r 0.00u 0.00s 0% > > 2704k > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.64r 0.00u 0.00s 0% > > 2716k > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.78r 0.00u 0.00s 0% > > 2760k > > > > this problem goes away after increasing vfs.zfs.arc_max > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > > > Previously, ZFS was not actually able to evict enough dnodes to keep > your arc_max under 128MB, it would have been much higher based on the > number of open files you had. A recent improvement from upstream ZFS > (r337653 and r337660) was pulled in that fixed this, so setting an > arc_max of 128MB is much more effective now, and that is causing the > side effect of "actually doing what you asked it to do", in this case, > what you are asking is a bit silly. If you have a working set that is > greater than 128MB, and you ask ZFS to use less than that, it'll have to > constantly try to reclaim memory to keep under that very low bar. > > -- > Allan Jude > Hi, Thanks for comments. Mark was right when he pointed to r338416 ( https://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c?r1=338416=338415=338416 ). Commenting aggsum_value returns normal speed regardless of the rest of the new code from upstream. I would like to repeat that the speed with these two lines is not just slow, but _INCREDIBLY_ slow! Probably, this should be written in the relevant documentation for FreeBSD 12+ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode
On 05.09.2018 17:51, Cy Schubert wrote: > I don't think you need something accurate. Ok, here is results. I'm working in single-user mode. TL;DR "Turbo" mode make "openssl" much slower (x3.5)! I can not properly interpret this result. But "turbostat" properly detect Turbo/No-Turbo mode, so it is not mistake in BIOS. (1) Trubo ENABLED, powerd IS NOT started dev.cpu.0.freq=480 no matter what. turbostat shows DIFFERENT speeds, like this (I've removed IRQ-related fields to fit in one line): Package Core CPU Avg_MHz Busy% Bzy_MHz TSC_MHz CPU%c1 CPU%c3 CPU%c6 - -- 2 0.30 135916006.18 0.00 93.52 31 0 00 2 0.36 863 16000.08 0.00 99.56 31 0 11 4 0.47 1462160024.56 0.00 74.96 31 1 02 2 0.22 167016000.05 0.00 99.72 29 1 13 2 0.14 179216000.02 0.00 99.84 29 "openssl speed aes-256-cbc": type16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256 cbc 5653.98k 6159.49k 6356.31k17271.70k17517.23k (2) Trubo ENABLED, powerd IS started dev.cpu.0.freq shows different values, from 60 in idle to 1601 under load. turbostat shows same values, but at idle Bzy_MHz drops low. openssl is the same type16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256 cbc 5580.78k 6155.97k 6349.23k17273.51k17511.77k (3) Trubo DISABLED, powerd IS NOT started dev.cpu.0.freq=1600 no matter what. turbostat shows higher numbers: Package Core CPU Avg_MHz Busy% Bzy_MHz TSC_MHz CPU%c1 CPU%c3 CPU%c6 - -- 2 0.21 180716001.44 0.00 98.35 38 0 00 3 0.28 176416000.06 0.00 99.66 38 0 11 3 0.24 205216001.72 0.00 98.03 38 1 02 1 0.09 162916000.02 0.00 99.89 36 1 13 2 0.22 166416003.94 0.00 95.84 36 "openssl speed aes-256-cbc": type16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256 cbc 18939.95k20638.71k21281.24k57836.36k58736.39k (3.5 times faster that with Turbo ENABLED!) (4) Trubo DISABLED, powerd IS started dev.cpu.0.freq shows different values, from 60 in idle to 1600 under load. turbostat shows very low Bzy_MHz on idle, but high (suspiciously high) under load: Package Core CPU Avg_MHz Busy% Bzy_MHz TSC_MHz CPU%c1 CPU%c3 CPU%c6 - -- 147592.22 26661600 1.66 0.00 6.1241 0 00 147592.22 26661600 1.62 0.00 6.1641 0 11 147592.21 26661600 1.41 0.00 6.3841 1 02 147592.21 26661600 1.78 0.00 6.0138 1 13 147692.24 26661600 1.84 0.00 5.9238 openssl is almost the same type16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256 cbc 16277.18k20620.71k21272.10k57998.35k58687.83k -- // Lev Serebryakov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode
On 05.09.2018 17:51, Cy Schubert wrote: > I don't think you need something accurate. 1.6GHz and 2.48Ghz.. Maybe... I i'm trying now. > We don't know whether it is implemented through ACPI or similar to the > old turbo jumper on the MB, which increased the clock rate and sometimes > the voltage ( required to maintain stability when increasing the clock > rate). We don't know how your MB manufacturer implemented this. I thought, it could be implemented only in one? official, way, as it is Intel's official technology, and not MoBo's one. -- // Lev Serebryakov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: newfs silently fails if random is not ready (?)
Differential up here: https://reviews.freebsd.org/D17049 for any
lurkers I didn't manage to tag in the review.
Best,
Conrad
On Wed, Sep 5, 2018 at 12:57 AM, Mark R V Murray wrote:
> Nice catch! Thanks :-)
>
> M
>
>
>> On 5 Sep 2018, at 04:13, Conrad Meyer wrote:
>>
>> Hi Lev,
>>
>> I took a first attempt at reproducing this problem on a fast
>> desktop-class system. First steps, give us a way to revert back to
>> unseeded status:
>>
>> --- a/sys/dev/random/fortuna.c
>> +++ b/sys/dev/random/fortuna.c
>> @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$");
>>
>> #ifdef _KERNEL
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -384,6 +385,17 @@ random_fortuna_pre_read(void)
>>return;
>>}
>>
>> + /*
>> +* When set, pretend we do not have enough entropy to reseed yet.
>> +*/
>> + KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_pre_read, {
>> + if (RETURN_VALUE != 0) {
>> + RANDOM_RESEED_UNLOCK();
>> + return;
>> + }
>> + });
>> +
>> +
>> #ifdef _KERNEL
>>fortuna_state.fs_lasttime = now;
>> #endif
>> @@ -442,5 +454,11 @@ bool
>> random_fortuna_seeded(void)
>> {
>>
>> + /* When set, act as if we are not seeded. */
>> + KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_seeded, {
>> + if (RETURN_VALUE != 0)
>> + fortuna_state.fs_counter = UINT128_ZERO;
>> + });
>> +
>>return (!uint128_is_zero(fortuna_state.fs_counter));
>> }
>>
>>
>> Second step, enable the failpoints and launch repro program:
>>
>> $ sudo sysctl debug.fail_point.random_fortuna_pre_read='return(1)'
>> debug.fail_point.random_fortuna_pre_read: off -> return(1)
>> $ sudo sysctl debug.fail_point.random_fortuna_seeded='return(1)'
>> debug.fail_point.random_fortuna_seeded: off -> return(1)
>>
>> $ cat ./blocked_random_poc.c
>> #include
>> #include
>> #include
>>
>> int
>> main(int argc, char **argv)
>> {
>>printf("%x\n", arc4random());
>>return (0);
>> }
>>
>>
>> $ ./blocked_random_poc
>> ...
>>
>>
>> Third step, I looked at what that process was doing:
>>
>> Curiously, it is not in getrandom() at all, but instead the ARND
>> sysctl fallback. I probably need to rebuild world (libc) to test this
>> (new libc arc4random based on Chacha).
>>
>> $ procstat -kk 1196
>> PIDTID COMMTDNAME KSTACK
>> 1196 100435 blocked_random_poc - read_random+0x3d
>> sysctl_kern_arnd+0x3a sysctl_root_handler_locked+0x89
>> sysctl_root.isra.8+0x167 userland_sysctl+0x126 sys___sysctl+0x7b
>> amd64_syscall+0x940 fast_syscall_common+0x101
>>
>>
>> When I unblocked the failpoints, it completed successfully:
>>
>> $ sudo sysctl debug.fail_point.random_fortuna_pre_read='off'
>> debug.fail_point.random_fortuna_pre_read: return(1) -> off
>> $ sudo sysctl debug.fail_point.random_fortuna_seeded=off
>> debug.fail_point.random_fortuna_seeded: return(1) -> off
>>
>> ...
>> 9e5eb30f
>>
>>
>> Best,
>> Conrad
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>>
>
> --
> Mark R V Murray
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4
On 2018-09-05 10:04, Subbsd wrote: > Hi, > > I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12 > to latest revision (r338466 the moment) and related to ARC. > > I can not say which revision was before except that the newver.sh > pointed to ALPHA3. > > Problems are observed if you try to limit ARC. In my case: > > vfs.zfs.arc_max="128M" > > I know that this is very small. However, for two years with this there > were no problems. > > When i send SIGINFO to process which is currently working with ZFS, i > see "arc_reclaim_waiters_cv": > > e.g when i type: > > /bin/csh > > I have time (~5 seconds) to press several times 'ctrl+t' before csh is > executed: > > load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.41r 0.00u 0.00s 0% 3512k > load: 0.70 cmd: csh 5935 [zio->io_cv] 1.69r 0.00u 0.00s 0% 3512k > load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.98r 0.00u 0.01s 0% 3512k > load: 0.73 cmd: csh 5935 [arc_reclaim_waiters_cv] 2.19r 0.00u 0.01s 0% 4156k > > same story with find or any other commans: > > load: 0.34 cmd: find 5993 [zio->io_cv] 0.99r 0.00u 0.00s 0% 2676k > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.13r 0.00u 0.00s 0% 2676k > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.25r 0.00u 0.00s 0% 2680k > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.38r 0.00u 0.00s 0% 2684k > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.51r 0.00u 0.00s 0% 2704k > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.64r 0.00u 0.00s 0% 2716k > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.78r 0.00u 0.00s 0% 2760k > > this problem goes away after increasing vfs.zfs.arc_max > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > Previously, ZFS was not actually able to evict enough dnodes to keep your arc_max under 128MB, it would have been much higher based on the number of open files you had. A recent improvement from upstream ZFS (r337653 and r337660) was pulled in that fixed this, so setting an arc_max of 128MB is much more effective now, and that is causing the side effect of "actually doing what you asked it to do", in this case, what you are asking is a bit silly. If you have a working set that is greater than 128MB, and you ask ZFS to use less than that, it'll have to constantly try to reclaim memory to keep under that very low bar. -- Allan Jude signature.asc Description: OpenPGP digital signature
RE: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode
I don't think you need something accurate. We don't know whether it is implemented through ACPI or similar to the old turbo jumper on the MB, which increased the clock rate and sometimes the voltage ( required to maintain stability when increasing the clock rate). We don't know how your MB manufacturer implemented this. My guess is it's probably through ACPI but you don't know until you have some rough measurements. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -Original Message- From: Lev Serebryakov Sent: 05/09/2018 06:46 To: Cy Schubert; Eric van Gyzen Cc: FreeBSD Current; freebsd-hack...@freebsd.org Subject: Re: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode On 05.09.2018 15:53, Cy Schubert wrote: >> 1601 is not the actual frequency. That is just how it is reported. It >> is almost certainly running much higher than 1601. > > We don't know this until we can independently verify it. Do you mind > running some benchmarks with and without turbo mode? What could be adequate benchmarks for this? Something likje "openssl speed aes128-cbc" or I need more specific one? -- // Lev Serebryakov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4
On Wed, Sep 05, 2018 at 05:04:56PM +0300, Subbsd wrote: > Hi, > > I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12 > to latest revision (r338466 the moment) and related to ARC. > > I can not say which revision was before except that the newver.sh > pointed to ALPHA3. Could you please try reverting r338416 to see if that fixes the problem? > Problems are observed if you try to limit ARC. In my case: > > vfs.zfs.arc_max="128M" > > I know that this is very small. However, for two years with this there > were no problems. Two years on -CURRENT? How often did you update? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4
Hi, I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12 to latest revision (r338466 the moment) and related to ARC. I can not say which revision was before except that the newver.sh pointed to ALPHA3. Problems are observed if you try to limit ARC. In my case: vfs.zfs.arc_max="128M" I know that this is very small. However, for two years with this there were no problems. When i send SIGINFO to process which is currently working with ZFS, i see "arc_reclaim_waiters_cv": e.g when i type: /bin/csh I have time (~5 seconds) to press several times 'ctrl+t' before csh is executed: load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.41r 0.00u 0.00s 0% 3512k load: 0.70 cmd: csh 5935 [zio->io_cv] 1.69r 0.00u 0.00s 0% 3512k load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.98r 0.00u 0.01s 0% 3512k load: 0.73 cmd: csh 5935 [arc_reclaim_waiters_cv] 2.19r 0.00u 0.01s 0% 4156k same story with find or any other commans: load: 0.34 cmd: find 5993 [zio->io_cv] 0.99r 0.00u 0.00s 0% 2676k load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.13r 0.00u 0.00s 0% 2676k load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.25r 0.00u 0.00s 0% 2680k load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.38r 0.00u 0.00s 0% 2684k load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.51r 0.00u 0.00s 0% 2704k load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.64r 0.00u 0.00s 0% 2716k load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.78r 0.00u 0.00s 0% 2760k this problem goes away after increasing vfs.zfs.arc_max ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Celeron J3160 with enabled Turbo mode stays at 480MHz (lowestsetting) forever and can not lower frequency without Tuebo mode
On 05.09.2018 15:53, Cy Schubert wrote: >> 1601 is not the actual frequency. That is just how it is reported. It >> is almost certainly running much higher than 1601. > > We don't know this until we can independently verify it. Do you mind > running some benchmarks with and without turbo mode? What could be adequate benchmarks for this? Something likje "openssl speed aes128-cbc" or I need more specific one? -- // Lev Serebryakov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Celeron J3160 with enabled Turbo mode stays at 480MHz (lowestsetting) forever and can not lower frequency without Tuebo mode
In message <43d68d5a-d8b7-965d-52a6-3eff6cdae...@vangyzen.net>, Eric van Gyzen writes: > On 9/5/18 4:35 AM, Lev Serebryakov wrote: > > BTW, these four settings in rc.conf(5) > > > >performance_cx_lowest > >performance_cpu_freq > >economy_cx_lowest > >economy_cpu_freq > > > > do NOTHING. They are not used ANYWHERE but rc.conf and rc.conf.5! > > They are used by /etc/rc.d/power_profile, but not in a way that grep can > find. > > > BTW, "Turbo mode enabled + dev.cpu.X.cx_lowset=C3 + powerd" works, but > > gives only 1601 Mhz, not 2240MHz max: > > > > TURBO ON: > > dev.cpu.0.freq_levels: 1601/2000 1600/2000 1520/1900 1440/1800 1360/1700 12 > 80/1600 1200/1500 1120/1400 1040/1300 960/1200 880/1100 800/1000 720/900 640/ > 800 560/700 480/600 420/525 360/450 300/375 240/300 180/225 120/150 60/75 > > > > TURBO OFF: > > dev.cpu.0.freq_levels: 1600/2000 1520/1900 1440/1800 1360/1700 1280/1600 12 > 00/1500 1120/1400 1040/1300 960/1200 880/1100 800/1000 720/900 640/800 560/70 > 0 480/600 420/525 360/450 300/375 240/300 180/225 120/150 60/75 > > 1601 is not the actual frequency. That is just how it is reported. It > is almost certainly running much higher than 1601. We don't know this until we can independently verify it. Do you mind running some benchmarks with and without turbo mode? -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Celeron J3160 with enabled Turbo mode stays at 480MHz (lowestsetting) forever and can not lower frequency without Tuebo mode
On 9/5/18 4:35 AM, Lev Serebryakov wrote: BTW, these four settings in rc.conf(5) performance_cx_lowest performance_cpu_freq economy_cx_lowest economy_cpu_freq do NOTHING. They are not used ANYWHERE but rc.conf and rc.conf.5! They are used by /etc/rc.d/power_profile, but not in a way that grep can find. BTW, "Turbo mode enabled + dev.cpu.X.cx_lowset=C3 + powerd" works, but gives only 1601 Mhz, not 2240MHz max: TURBO ON: dev.cpu.0.freq_levels: 1601/2000 1600/2000 1520/1900 1440/1800 1360/1700 1280/1600 1200/1500 1120/1400 1040/1300 960/1200 880/1100 800/1000 720/900 640/800 560/700 480/600 420/525 360/450 300/375 240/300 180/225 120/150 60/75 TURBO OFF: dev.cpu.0.freq_levels: 1600/2000 1520/1900 1440/1800 1360/1700 1280/1600 1200/1500 1120/1400 1040/1300 960/1200 880/1100 800/1000 720/900 640/800 560/700 480/600 420/525 360/450 300/375 240/300 180/225 120/150 60/75 1601 is not the actual frequency. That is just how it is reported. It is almost certainly running much higher than 1601. Eric ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: newfs silently fails if random is not ready (?)
Hello Conrad,
Wednesday, September 5, 2018, 7:39:07 AM, you wrote:
> I believe the EWOULDBLOCK is just a boring leak of tsleep(9)'s timeout
> condition. This may be sufficient to fix the problem:
> --- a/sys/dev/random/randomdev.c
> +++ b/sys/dev/random/randomdev.c
> @@ -156,6 +156,10 @@ READ_RANDOM_UIO(struct uio *uio, bool nonblock)
> error = tsleep(_alg_context, PCATCH, "randseed",
> hz/10);
> if (error == ERESTART || error == EINTR)
> break;
> + /* Squash hz/10 timeout condition */
> + if (error == EWOULDBLOCK)
> + error = 0;
> + KASSERT(error == 0, ("unexpected %d", error));
> }
> if (error == 0) {
> read_rate_increment((uio->uio_resid +
> sizeof(uint32_t))/sizeof(uint32_t));
Fantastic! Thanks!
--
Best regards,
Levmailto:l...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Celeron J3160 with enabled Turbo mode stays at 480MHz (lowestsetting) forever and can not lower frequency without Tuebo mode
Hello Cy, Wednesday, September 5, 2018, 3:12:34 AM, you wrote: > Are you running powers? powerd? yes. With "adaptive" strategy" > Do you use c-states? Oops. My fault. I've forgot to set cx_lowest to C3 on all cores. BTW, these four settings in rc.conf(5) performance_cx_lowest performance_cpu_freq economy_cx_lowest economy_cpu_freq do NOTHING. They are not used ANYWHERE but rc.conf and rc.conf.5! > What happens if you boot in (instead of switch to) turbo mode? Sorry? I could only turn Turbo mode on/off in BIOS before boot. BTW, "Turbo mode enabled + dev.cpu.X.cx_lowset=C3 + powerd" works, but gives only 1601 Mhz, not 2240MHz max: TURBO ON: dev.cpu.0.freq_levels: 1601/2000 1600/2000 1520/1900 1440/1800 1360/1700 1280/1600 1200/1500 1120/1400 1040/1300 960/1200 880/1100 800/1000 720/900 640/800 560/700 480/600 420/525 360/450 300/375 240/300 180/225 120/150 60/75 TURBO OFF: dev.cpu.0.freq_levels: 1600/2000 1520/1900 1440/1800 1360/1700 1280/1600 1200/1500 1120/1400 1040/1300 960/1200 880/1100 800/1000 720/900 640/800 560/700 480/600 420/525 360/450 300/375 240/300 180/225 120/150 60/75 But I could live with that :-) -- Best regards, Levmailto:l...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: newfs silently fails if random is not ready (?)
Nice catch! Thanks :-)
M
> On 5 Sep 2018, at 04:13, Conrad Meyer wrote:
>
> Hi Lev,
>
> I took a first attempt at reproducing this problem on a fast
> desktop-class system. First steps, give us a way to revert back to
> unseeded status:
>
> --- a/sys/dev/random/fortuna.c
> +++ b/sys/dev/random/fortuna.c
> @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$");
>
> #ifdef _KERNEL
> #include
> +#include
> #include
> #include
> #include
> @@ -384,6 +385,17 @@ random_fortuna_pre_read(void)
>return;
>}
>
> + /*
> +* When set, pretend we do not have enough entropy to reseed yet.
> +*/
> + KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_pre_read, {
> + if (RETURN_VALUE != 0) {
> + RANDOM_RESEED_UNLOCK();
> + return;
> + }
> + });
> +
> +
> #ifdef _KERNEL
>fortuna_state.fs_lasttime = now;
> #endif
> @@ -442,5 +454,11 @@ bool
> random_fortuna_seeded(void)
> {
>
> + /* When set, act as if we are not seeded. */
> + KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_seeded, {
> + if (RETURN_VALUE != 0)
> + fortuna_state.fs_counter = UINT128_ZERO;
> + });
> +
>return (!uint128_is_zero(fortuna_state.fs_counter));
> }
>
>
> Second step, enable the failpoints and launch repro program:
>
> $ sudo sysctl debug.fail_point.random_fortuna_pre_read='return(1)'
> debug.fail_point.random_fortuna_pre_read: off -> return(1)
> $ sudo sysctl debug.fail_point.random_fortuna_seeded='return(1)'
> debug.fail_point.random_fortuna_seeded: off -> return(1)
>
> $ cat ./blocked_random_poc.c
> #include
> #include
> #include
>
> int
> main(int argc, char **argv)
> {
>printf("%x\n", arc4random());
>return (0);
> }
>
>
> $ ./blocked_random_poc
> ...
>
>
> Third step, I looked at what that process was doing:
>
> Curiously, it is not in getrandom() at all, but instead the ARND
> sysctl fallback. I probably need to rebuild world (libc) to test this
> (new libc arc4random based on Chacha).
>
> $ procstat -kk 1196
> PIDTID COMMTDNAME KSTACK
> 1196 100435 blocked_random_poc - read_random+0x3d
> sysctl_kern_arnd+0x3a sysctl_root_handler_locked+0x89
> sysctl_root.isra.8+0x167 userland_sysctl+0x126 sys___sysctl+0x7b
> amd64_syscall+0x940 fast_syscall_common+0x101
>
>
> When I unblocked the failpoints, it completed successfully:
>
> $ sudo sysctl debug.fail_point.random_fortuna_pre_read='off'
> debug.fail_point.random_fortuna_pre_read: return(1) -> off
> $ sudo sysctl debug.fail_point.random_fortuna_seeded=off
> debug.fail_point.random_fortuna_seeded: return(1) -> off
>
> ...
> 9e5eb30f
>
>
> Best,
> Conrad
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP
