date:20170813

Re: TSC timekeeping and cpu states

2017-08-13 Thread Kevin Oberman

On Sun, Aug 13, 2017 at 8:25 PM, Aristedes Maniatis  wrote:

> I note that in FreeBSD 11, we now have this:
>
> # grep performance_cx_lowest /etc/defaults/rc.conf
> performance_cx_lowest="C2"  # Online CPU idle state
>
> However this wiki page suggests that C1 is the default
>
> https://wiki.freebsd.org/TuningPowerConsumption
>
>
> Are these inconsistent?
>
>
> I went looking for this because I've been having trouble with the TSC-low
> timecounter hardware choice and my system clock running at about 80% of
> normal speed. Moving to ACPI-fast solved this problem.
>
> Could the power saving CPU states be related to this problem, or should I
> look elsewhere for the TSC issue?
>
> This is a server, not a laptop.
>
>
> Thanks
> Ari
>
>
>
> --
> -->
> Aristedes Maniatis
> CEO, ish
> https://www.ish.com.au
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>

Again, the documentation lags reality. The default was changed for 11.0. It
is still conservative. In ALMOST all cases, Cmax will yield the bast
results. However, on large systems with many cores, Cmax will trigger very
poor results, so the default is C2, just to be safe.

As far as possible TSC impact, I think older processors had TSC issues when
not all cores ran with the same clock speed. That said, I am not remotely
expert on such issues, so don't take this too seriously.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

TSC timekeeping and cpu states

2017-08-13 Thread Aristedes Maniatis

I note that in FreeBSD 11, we now have this:

# grep performance_cx_lowest /etc/defaults/rc.conf
performance_cx_lowest="C2"  # Online CPU idle state

However this wiki page suggests that C1 is the default

https://wiki.freebsd.org/TuningPowerConsumption


Are these inconsistent?


I went looking for this because I've been having trouble with the TSC-low 
timecounter hardware choice and my system clock running at about 80% of normal 
speed. Moving to ACPI-fast solved this problem.

Could the power saving CPU states be related to this problem, or should I look 
elsewhere for the TSC issue?

This is a server, not a laptop.


Thanks
Ari



-- 
-->
Aristedes Maniatis
CEO, ish
https://www.ish.com.au
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

UNAME_r () and OSVERSION (1101501) do not agree on major version number , which poudriere bulk rejects as a combination.

2017-08-13 Thread Mark Millard

The summary:

My attempts to use poudriere-devel via a -m null
-M /usr/obj/DESTDIRs/FBSDx6411SL-installworld-dist-from-src
based jail and a -m null -M /usr/ports based ports 
got:

make: "/usr/ports/Mk/bsd.port.mk" line 1177: UNAME_r () and OSVERSION (1101501) 
do not agree on major version number.

This suggests that in /usr/ports/Mk/bsd.ports.mk the
logic:

# Get the architecture
.if !defined(ARCH)
ARCH!=  ${UNAME} -p
.endif
_EXPORTED_VARS+=ARCH

# Get the operating system type
.if !defined(OPSYS)
OPSYS!= ${UNAME} -s
.endif
_EXPORTED_VARS+=OPSYS

.if !defined(_OSRELEASE)
_OSRELEASE!=${UNAME} -r
.endif
_EXPORTED_VARS+=_OSRELEASE

# Get the operating system revision
OSREL?= ${_OSRELEASE:C/-.*//}
_EXPORTED_VARS+=OSREL

is not getting the expected values for use in the
later logic, in this case _OSRELEASE:

.if ${_OSVERSION_MAJOR} != ${_OSRELEASE:R}
.error UNAME_r (${_OSRELEASE}) and OSVERSION (${OSVERSION}) do not agree on 
major version number.
.elif ${_OSVERSION_MAJOR} != ${OSREL:R}
.error OSREL (${OSREL}) and OSVERSION (${OSVERSION}) do not agree on major 
version number.
.endif


(The message's reference to UNAME_r also looks odd since it
is not used in the .if expression or anywhere nearby but there
is such a name in the login.conf default .)

A testing hack of:

# svnlite diff /usr/ports/Mk/bsd.port.mk


Index: /usr/ports/Mk/bsd.port.mk
===
--- /usr/ports/Mk/bsd.port.mk   (revision 447897)
+++ /usr/ports/Mk/bsd.port.mk   (working copy)
@@ -1119,18 +1119,18 @@
 
 # Get the architecture
 .if !defined(ARCH)
-ARCH!= ${UNAME} -p
+ARCH!= echo amd64
 .endif
 _EXPORTED_VARS+=   ARCH
 
 # Get the operating system type
 .if !defined(OPSYS)
-OPSYS!=${UNAME} -s
+OPSYS!=echo FreeBSD
 .endif
 _EXPORTED_VARS+=   OPSYS
 
 .if !defined(_OSRELEASE)
-_OSRELEASE!=   ${UNAME} -r
+_OSRELEASE!=   echo 11.1-STABLE
 .endif
 _EXPORTED_VARS+=   _OSRELEASE


got past the specific issue.

But it later got:

/usr/local/share/poudriere/bulk.sh: cannot open 
/usr/local/etc/poudriere.d/jails/zrFBSDx64SLjail/version: No such file or 
directory

via:

[00:00:00] Creating the reference jail... done
[00:00:04] Mounting system devices for zrFBSDx64SLjail-default
[00:00:04] Mounting ports/packages/distfiles
[00:00:04] Using packages from previously failed build
[00:00:04] Mounting packages from: 
/usr/local/poudriere/data/packages/zrFBSDx64SLjail-default
/etc/resolv.conf -> 
/usr/local/poudriere/data/.m/zrFBSDx64SLjail-default/ref/etc/resolv.conf
[00:00:04] Starting jail zrFBSDx64SLjail-default
[00:00:05] Logs: 
/usr/local/poudriere/data/logs/bulk/zrFBSDx64SLjail-default/2017-08-13_18h39m47s
[00:00:06] Loading MOVED
[00:00:06] Ports supports: DEPENDS_ARGS SELECTED_OPTIONS
[00:00:06] Gathering ports metadata
[00:06:18] Calculating ports order and dependencies
[00:09:13] pkg package missing, skipping sanity
[00:09:13] Skipping incremental rebuild and repository sanity checks
[00:09:13] Cleaning the build queue
[00:09:13] Sanity checking build queue
[00:09:16] Processing PRIORITY_BOOST
[00:09:24] Balancing pool
/usr/local/share/poudriere/bulk.sh: cannot open 
/usr/local/etc/poudriere.d/jails/zrFBSDx64SLjail/version: No such file or 
directory

# ls -lT /usr/local/etc/poudriere.d/jails/zrFBSDx64SLjail/
total 3
-rw-r--r--  1 root  wheel   6 Aug 13 17:30:39 2017 arch
-rw-r--r--  1 root  wheel   5 Aug 13 17:30:39 2017 method
-rw-r--r--  1 root  wheel  57 Aug 13 17:30:39 2017 mnt
-rw-r--r--  1 root  wheel   9 Aug 13 17:30:39 2017 srcpath
-rw-r--r--  1 root  wheel  11 Aug 13 17:30:39 2017 timestamp


(I've not tracked this part down at all yet.)



More details on the sequence I went through:

I installed FreeBSD-11.1-STABLE-amd64-20170807-r322164-disc1.iso
into a new VirtualBox virtual machine and then checked
out:

# svnlite info /usr/src/ | grep "Re[plv]"
Relative URL: ^/stable/11
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 322433
Last Changed Rev: 322433

and did buildworld buildkernel installkernel installworld .

I also then installed this ( installworld distrib-dirs
distribution ) to:

# ls -dlT /usr/obj/DESTDIRs/*
drwxr-xr-x  18 root  wheel  22 Aug 13 17:28:54 2017 
/usr/obj/DESTDIRs/FBSDx6411SL-installworld-dist-from-src

The result for uname is:

# uname -apKU
FreeBSD FBSDx6411SL 11.1-STABLE FreeBSD 11.1-STABLE  r322433  amd64 amd64 
1101501 1101501

# uname -r
11.1-STABLE

I used pkg to install poudriere-devel :

# pkg info poudriere-devel
poudriere-devel-3.1.99.20170803
Name   : poudriere-devel
Version: 3.1.99.20170803
Installed on   : Sun Aug 13 16:08:56 2017 PDT
Origin : ports-mgmt/poudriere-devel
Architecture   : FreeBSD:11:amd64
Prefix : /usr/local
Categories :

Re: zfs listing and CPU

2017-08-13 Thread Eugene M. Zheganin


On 13.08.2017 16:13, Tenzin Lhakhang wrote:
You may want to have an async zfs-get program/script that regularly 
does a zfs get -Ho and stores then in a local cache (redis or your own 
program) at a set interval and then the api can hit the cache instead 
of directly running get or list.
I cannot because the cache will become stale on first new entity 
creation, which happens all the time.


- Some silly person will try to benchmark your zfs web-API and 
overload your server with zfs processes.

- Example: let me run [ ab -c 10 -n 1 http://yourserver/zfs-api/list ]
-- Let me run 10 concurrent connection with a total of 10k requests to 
your api (it's a simple one liner -- people will be tempted to 
benchmark like this).


Example:
https://github.com/tlhakhan/ideal-potato/blob/master/zdux/routers/zfs/service.js#L9
- This is a JS example, but you can easily script it or another 
language (golang) for cache separation and another program for the API.


Also, zfs does have a -c property to get cached values -- these values 
are stored in an internal zfs process cache. The -c doesn't help if 
you have 1000(0)s of filesystems, a single list can still take 
minutes.  Sending the list is also several megabytes.

Doesn't have on FreeBSD.


Thanks.
Eugene.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Error in 'make buildworld' on 10.3

2017-08-13 Thread Aijaz Baig

I am trying to buildworld on 10.3 and I encounter an error:

--- _worldtmp ---
--
>>> Rebuilding the temporary build tree
--
rm -rf /mnt/ObjDir/usr/src/tmp
rm -rf /mnt/ObjDir/usr/src/lib32
mkdir -p /mnt/ObjDir/usr/src/tmp/lib
mkdir -p /mnt/ObjDir/usr/src/tmp/usr
mkdir -p /mnt/ObjDir/usr/src/tmp/legacy/bin
mkdir -p /mnt/ObjDir/usr/src/tmp/legacy/usr
mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist  -p
/mnt/ObjDir/usr/src/tmp/legacy/usr >/dev/null
mtree -deU -f /usr/src/etc/mtree/BSD.groff.dist  -p
/mnt/ObjDir/usr/src/tmp/legacy/usr >/dev/null
mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist  -p
/mnt/ObjDir/usr/src/tmp/usr >/dev/null
mtree -deU -f /usr/src/etc/mtree/BSD.include.dist  -p
/mnt/ObjDir/usr/src/tmp/usr/include >/dev/null
ln -sf /usr/src/sys /mnt/ObjDir/usr/src/tmp
--- _legacy ---
--
>>> stage 1.1: legacy release compatibility shims
--
cd /usr/src; MAKEOBJDIRPREFIX=/mnt/ObjDir/usr/src/tmp  INSTALL="sh
/usr/src/tools/install.sh"
 
PATH=/mnt/ObjDir/usr/src/tmp/legacy/usr/sbin:/mnt/ObjDir/usr/src/tmp/legacy/usr/bin:/mnt/ObjDir/usr/src/tmp/legacy/usr/games:/mnt/ObjDir/usr/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
 WORLDTMP=/mnt/ObjDir/usr/src/tmp  VERSION="FreeBSD 10.3-RELEASE amd64
1003000"  MAKEFLAGS="-m /usr/src/tools/build/mk  -j 4 -J 15,16 -m
/usr/src/share/mk"  COMPILER_TYPE=clang make  -f Makefile.inc1  DESTDIR=
 BOOTSTRAPPING=1003000  SSP_CFLAGS=  -DWITHOUT_HTML -DWITHOUT_INFO
-DNO_LINT -DWITHOUT_MAN  -DNO_PIC -DNO_PROFILE -DNO_SHARED
 _BOOTSTRAP_MAKEINFO=yes  -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF -DEARLY_BUILD
-DNO_TESTS legacy
--- legacy ---
===> tools/build (obj,includes,depend,all,install)
--- obj ---
/mnt/ObjDir/usr/src/tmp/usr/src/tools/build created for /usr/src/tools/build
--- includes ---
; cd /usr/src/tools/build; make buildincludes; make installincludes
--- .depend ---
rm -f .depend
mkdep -f .depend -a-I/mnt/ObjDir/usr/src/tmp/legacy/usr/include
-std=gnu99/usr/src/tools/build/../../contrib/libc-pwcache/pwcache.c
/usr/src/tools/build/../../contrib/libc-pwcache/pwcache.c:82:10: fatal
error: 'namespace.h' file not found
#include "namespace.h"
 ^
1 error generated.
mkdep: compile failed
*** [.depend] Error code 1

make[3]: stopped in /usr/src/tools/build
1 error

make[3]: stopped in /usr/src/tools/build
*** [legacy] Error code 2

make[2]: stopped in /usr/src
1 error

make[2]: stopped in /usr/src
*** [_legacy] Error code 2

make[1]: stopped in /usr/src
1 error

make[1]: stopped in /usr/src
*** [buildworld] Error code 2

make: stopped in /usr/src
1 error

make: stopped in /usr/src

What is this error? Am I missing certain header files? Keen to hear
-- 

Best Regards,
Aijaz Baig
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zfs listing and CPU

2017-08-13 Thread Tenzin Lhakhang

You may want to have an async zfs-get program/script that regularly does a
zfs get -Ho and stores then in a local cache (redis or your own program) at
a set interval and then the api can hit the cache instead of directly
running get or list.
- Some silly person will try to benchmark your zfs web-API and overload
your server with zfs processes.
- Example: let me run [ ab -c 10 -n 1 http://yourserver/zfs-api/list ]
-- Let me run 10 concurrent connection with a total of 10k requests to your
api (it's a simple one liner -- people will be tempted to benchmark like
this).

Example:
https://github.com/tlhakhan/ideal-potato/blob/master/zdux/routers/zfs/service.js#L9
- This is a JS example, but you can easily script it or another language
(golang) for cache separation and another program for the API.

Also, zfs does have a -c property to get cached values -- these values are
stored in an internal zfs process cache.  The -c doesn't help if you have
1000(0)s of filesystems, a single list can still take minutes.  Sending the
list is also several megabytes.

zfs list -Hrpc -o space

zfs get -Hrpc space all

- H= no headers
- r = recursive
- p = machine parseable
- c = hit cached entries

Fixes:  if ok, it may be good to stop the API, kill slowly the zfs list -t
all.

@ Eugene:
- I have seen single zfs list -Ho space -rt all take about 4-5 minutes, on
an 8000+ zfs_dataset zpool.

---
Notes:  my knowledge is from the illumos-zfs man pages but should apply
here.


On Sun, Aug 13, 2017 at 6:09 AM, Eugene M. Zheganin 
wrote:

> Hi,
>
> On 12.08.2017 20:50, Paul Kraus wrote:
>
>> On Aug 11, 2017, at 2:28 AM, Eugene M. Zheganin 
>>> wrote:
>>>
>>> Why does the zfs listing eat so much of the CPU ?
>>> 47114 root   1  200 40432K  3840K db->db  4   0:05 26.84% zfs
>>> 47099 root   1  200 40432K  3840K zio->i 17   0:05 26.83% zfs
>>> 47106 root   1  200 40432K  3840K db->db 21   0:05 26.81% zfs
>>> 47150 root   1  200 40432K  3428K db->db 13   0:03 26.31% zfs
>>> 47141 root   1  200 40432K  3428K zio->i 28   0:03 26.31% zfs
>>> 47135 root   1  200 40432K  3312K g_wait  9   0:03 25.51% zfs
>>> This is from winter 2017 11-STABLE (r310734), one of the 'zfs'es is
>>> cloning, and all the others are 'zfs list -t all'. I have like 25 gigs of
>>> free RAM, do I have any chance of speeding this up using may be some
>>> caching or some sysctl tuning ? We are using a simple ZFS web API that may
>>> issue concurrent or sequential listing requests, so as you can see they
>>> sometimes do stack.
>>>
>> How many snapshots do you have ? I have only seen this behavior with LOTS
>> (not hundreds, but thousands) of snapshots.
>>
> [root@san1:~]# zfs list -t snapshot | wc -l
>   88
>
>> What does your `iostat -x 1` look like ? I expect that you are probably
>> saturating your drives with random I/O.
>>
>
> Well, it's really long, and the disks are busy with random i/o indeed, but
> byst only for 20-30%. As about iostat - it's really long, because I have
> hundreds (not thousands) of zvols, and they do show up in iostat -x. But
> nothing unusual besides that.
>
>
> Thanks.
>
> Eugene.
>
>
> ___
> freebsd...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zfs listing and CPU

2017-08-13 Thread Eugene M. Zheganin


Hi,

On 12.08.2017 20:50, Paul Kraus wrote:

On Aug 11, 2017, at 2:28 AM, Eugene M. Zheganin  wrote:

Why does the zfs listing eat so much of the CPU ?
47114 root   1  200 40432K  3840K db->db  4   0:05 26.84% zfs
47099 root   1  200 40432K  3840K zio->i 17   0:05 26.83% zfs
47106 root   1  200 40432K  3840K db->db 21   0:05 26.81% zfs
47150 root   1  200 40432K  3428K db->db 13   0:03 26.31% zfs
47141 root   1  200 40432K  3428K zio->i 28   0:03 26.31% zfs
47135 root   1  200 40432K  3312K g_wait  9   0:03 25.51% zfs
This is from winter 2017 11-STABLE (r310734), one of the 'zfs'es is cloning, 
and all the others are 'zfs list -t all'. I have like 25 gigs of free RAM, do I 
have any chance of speeding this up using may be some caching or some sysctl 
tuning ? We are using a simple ZFS web API that may issue concurrent or 
sequential listing requests, so as you can see they sometimes do stack.

How many snapshots do you have ? I have only seen this behavior with LOTS (not 
hundreds, but thousands) of snapshots.

[root@san1:~]# zfs list -t snapshot | wc -l
  88

What does your `iostat -x 1` look like ? I expect that you are probably 
saturating your drives with random I/O.


Well, it's really long, and the disks are busy with random i/o indeed, 
but byst only for 20-30%. As about iostat - it's really long, because I 
have hundreds (not thousands) of zvols, and they do show up in iostat 
-x. But nothing unusual besides that.



Thanks.

Eugene.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: TSC timekeeping and cpu states

TSC timekeeping and cpu states

UNAME_r () and OSVERSION (1101501) do not agree on major version number , which poudriere bulk rejects as a combination.

Re: zfs listing and CPU

Error in 'make buildworld' on 10.3

Re: zfs listing and CPU

Re: zfs listing and CPU

7 matches

Site Navigation

Mail list logo

Footer information