From owner-svn-src-head@freebsd.org Fri Jun 14 14:25:10 2019 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3475215D0D88; Fri, 14 Jun 2019 14:25:10 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3A7996D4AE; Fri, 14 Jun 2019 14:25:08 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id 301333DBD9D; Sat, 15 Jun 2019 00:25:05 +1000 (AEST) Date: Sat, 15 Jun 2019 00:25:03 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alexander Motin cc: Bruce Evans , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r349029 - head/sys/kern In-Reply-To: <399ec4d3-6548-1145-4dea-f0b7850f8381@FreeBSD.org> Message-ID: <20190614235433.H1624@besplex.bde.org> References: <201906140109.x5E19Aj9087899@repo.freebsd.org> <20190614214154.I1201@besplex.bde.org> <399ec4d3-6548-1145-4dea-f0b7850f8381@FreeBSD.org> MIME-Version: 1.0 X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=FNpr/6gs c=1 sm=1 tr=0 cx=a_idp_d a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=nlC_4_pT8q9DhB4Ho9EA:9 a=-xne-0-MPzg3U2qvO0wA:9 a=45ClL6m2LaAA:10 X-Rspamd-Queue-Id: 3A7996D4AE X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.987,0] Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2019 14:25:10 -0000 On Fri, 14 Jun 2019, Alexander Motin wrote: > On 14.06.2019 08:58, Bruce Evans wrote: >> On Fri, 14 Jun 2019, Alexander Motin wrote: >> >>> Log: >>> =C2=A0Update td_runtime of running thread on each statclock(). >>> >>> =C2=A0Normally td_runtime is updated on context switch, but there are s= ome >>> kernel >>> =C2=A0threads that due to high absolute priority may run for many secon= ds >>> without >>> =C2=A0context switches (yes, that is bad, but that is true), which mean= s their >>> =C2=A0td_runtime was not updated all that time, that made them invisibl= e >>> for top >>> =C2=A0other then as some general CPU usage. >>> >>> =C2=A0MFC after:=C2=A0=C2=A0=C2=A0 1 week >>> =C2=A0Sponsored by:=C2=A0=C2=A0=C2=A0 iXsystems, Inc. >> >> This and more is supposed to be done in calcru().=C2=A0 It is also neces= sary to >> adjust for the current timeslice. >> >> I thought that calcru() was fixed, but the fix seems to be only in my >> version of FreeBSD-5.2. >> >> The bug seems to be in fill_kinfo_proc_only().=C2=A0 calcru() should upd= ate >> td_runtime for all threads in the proc (and sum into rux_rutime), > > ... > >> td_runtime is updated in one other place: in rufetchtd(), but this funct= ion >> has the same bug eas everywhere else -- it only updates the runtimes for >> curthread. > > I think it has very simple reason -- now each CPU measures CPU time in > its own time units, since cpu_ticks() are not synchronized and can not > be compared between different CPUs, so to update td_runtime of another > running thread you would need to switch to that CPU, or somehow else get > the value (cache it periodically?). I forgot about that bugfeature in the cpu ticker. > I see in your code you are using binuptime() calls instead of > cpu_ticks(). I suppose it fixes many problems, since it is globally > synchronous, but there was a reason why cpu_ticks() exists -- it is > cheaper on system non-synchronized TSC. May be we could reconsider > that, giving up on old platforms, expecting all new one to not have this > problem, but for right now I think my patch is good enough to make top > sane again, that annoyed me for years. It was written before the cpu ticker existed. cpu_ticks() exists because bintime() is too slow if the timecounter hardwar= e is too slow. i8254 timecounter hardware takes about 5 usec, ACPI timer about 1 usec, and HPET many hundreds of nsec. And of course, non-synchronized TSCs make the TSC unusable as a timecounter, so require use of a slow timecounter. Some systems don't have a TSC, so they use a timecounter for the cpu ticker anyway. There are many other bugs in the cpu ticker which only became not too bad when P-state invariant TSCs became common. The largest one is that all ticks are scaled at the current cpu ticker frequency. If synchronized P-state invariant TSCs are available, then the cpu ticker reduces to a micro-optimization. My code is used mainly on UP systems with TSC timecounters. I don't have any systems without a TSC, and UP avoids the problems of synchronization, and not throttling the CPU avoids the problem of the frequency changing, and I never noticed the micro-pessimization of using bintime() for the cpu ticker. I never noticed the problem in -current either, though I use my version of SCHED_4BSD with lots of tuning to reduce context switches. The tuning ofte= n results in threads running for a full quantum (100 msec) before switching, but I never noticed threads not switching for several seconds. Bruce From owner-svn-src-head@freebsd.org Fri Jun 14 17:09:41 2019 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F29DC15ABE0F; Fri, 14 Jun 2019 17:09:40 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9539471DBC; Fri, 14 Jun 2019 17:09:40 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 6783B1AB96; Fri, 14 Jun 2019 17:09:40 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id x5EH9eWa079445; Fri, 14 Jun 2019 17:09:40 GMT (envelope-from mav@FreeBSD.org) Received: (from mav@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id x5EH9eka079444; Fri, 14 Jun 2019 17:09:40 GMT (envelope-from mav@FreeBSD.org) Message-Id: <201906141709.x5EH9eka079444@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: mav set sender to mav@FreeBSD.org using -f From: Alexander Motin Date: Fri, 14 Jun 2019 17:09:40 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r349035 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys X-SVN-Group: head X-SVN-Commit-Author: mav X-SVN-Commit-Paths: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys X-SVN-Commit-Revision: 349035 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 9539471DBC X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.94 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.94)[-0.944,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2019 17:09:41 -0000 Author: mav Date: Fri Jun 14 17:09:39 2019 New Revision: 349035 URL: https://svnweb.freebsd.org/changeset/base/349035 Log: Properly align struct multilist_sublist to cache line. Manual Illumos alignment does not fit us due to different kmutex_t size. MFC after: 1 week Sponsored by: iXsystems, Inc. Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/multilist.h Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/multilist.h ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/multilist.h Fri Jun 14 15:09:08 2019 (r349034) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/multilist.h Fri Jun 14 17:09:39 2019 (r349035) @@ -44,11 +44,10 @@ struct multilist_sublist { */ list_t mls_list; /* - * Pad to cache line (64 bytes), in an effort to try and prevent - * cache line contention. + * Pad to cache line, in an effort to try and prevent cache line + * contention. */ - uint8_t mls_pad[24]; -}; +} __aligned(CACHE_LINE_SIZE); struct multilist { /*