From owner-freebsd-stable@freebsd.org Sun Apr 1 16:25:26 2018 Return-Path: Delivered-To: freebsd-stable@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 403F3F6AF60 for ; Sun, 1 Apr 2018 16:25:26 +0000 (UTC) (envelope-from cmt@burggraben.net) Received: from smtp.burggraben.net (smtp.burggraben.net [IPv6:2a01:4f8:140:50a2::3:1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "ns.exwg.net", Issuer "Christoph Moench-Tegeder" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C39C073074 for ; Sun, 1 Apr 2018 16:25:25 +0000 (UTC) (envelope-from cmt@burggraben.net) Received: from localhost (localhost [127.0.0.1]) by smtp.burggraben.net (Postfix) with ESMTP id 1E0586002F3 for ; Sun, 1 Apr 2018 18:25:23 +0200 (CEST) X-Spam-Scanned: by amavisd-new at exwg.net Received: from smtp.burggraben.net ([127.0.0.1]) by localhost (ns.burggraben.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAPh90UkPA-Z for ; Sun, 1 Apr 2018 18:25:12 +0200 (CEST) Received: from elch.exwg.net (elch.exwg.net [IPv6:2001:470:7120:1:127b:44ff:fe4f:148d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "elch.exwg.net", Issuer "Christoph Moench-Tegeder" (verified OK)) by smtp.burggraben.net (Postfix) with ESMTPS for ; Sun, 1 Apr 2018 18:25:12 +0200 (CEST) Received: by elch.exwg.net (Postfix, from userid 1000) id DF2A327323; Sun, 1 Apr 2018 18:25:11 +0200 (CEST) Date: Sun, 1 Apr 2018 18:25:11 +0200 From: Christoph Moench-Tegeder To: freebsd-stable@freebsd.org Subject: Panic with Dual-Band WLANs on ath Message-ID: <20180401162511.GA52648@elch.exwg.net> Mail-Followup-To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 16:25:26 -0000 Hi, I've got a fairly reproducable kernel panic when trying to configure two wlan devices on one ath card. The basics: FreeBSD 11.1-RELEASE-p8 amd64 ath0@pci0:4:0:0: class=0x028000 card=0x3099168c chip=0x002a168c rev=0x01 hdr=0x00 vendor = 'Qualcomm Atheros' device = 'AR928X Wireless Network Adapter (PCI-Express)' class = network (This is a Compex WLE200NX miniPCIe card in a PCEngines APU2: https://www.compex.com.sg/product/wle200nx/ for specifications). I want to create two access points on this device: one in 5Ghz and one in 2.4GHz (5GHz gives good bandwidth, but cannot radio it's way out of a cardboard box, so rather less-than-good coverage - and I still have hardware which is not 5GHz capable; 2.4GHz has less bandwidth but much better coverage (this is also true for my neighbours' networks, so I've got quite some interference here)). The naive approach was setting wlans_ath0="wlan0 wlan1" in rc.conf, and configuring wlan0 and wlan1 in parallel (hostap and stuff). Unfortunately, after short time (30 seconds to 5 minutes), I get a kernel panic: ath0: ath_rate_tx_complete: ts_rate=11 ts_finaltsi=0, final_rix=4 ath0: bad series0 hwrate 0xb, tries 7 ts_status 0x1 Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff8164aefc stack pointer = 0x28:0xfffffe011bbfe8a0 frame pointer = 0x28:0xfffffe011bbfe8f0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq40: ath0) trap number = 12 panic: page fault cpuid = 2 KDB: stack backtrace: #0 0xffffffff80585997 at kdb_backtrace+0x67 #1 0xffffffff80543a76 at vpanic+0x186 #2 0xffffffff805438e3 at panic+0x43 #3 0xffffffff8087c642 at trap_fatal+0x322 #4 0xffffffff8087c69b at trap_pfault+0x4b #5 0xffffffff8087beba at trap+0x2ca #6 0xffffffff8085ed20 at calltrap+0x8 #7 0xffffffff814e25c5 at ath_beacon_generate+0x45 #8 0xffffffff814e244b at ath_beacon_proc+0x22b #9 0xffffffff814d066d at ath_intr+0x24d #10 0xffffffff8050a0bc at intr_event_execute_handlers+0xec #11 0xffffffff8050a3a6 at ithread_loop+0xd6 #12 0xffffffff80507715 at fork_exit+0x85 #13 0xffffffff8085f9ee at fork_trampoline+0xe I can provide core dumps on request. Is this a case of "don't do that"? In that case, an error message instead of a kernel panic would be nice - it took me several roundtrips to disable the wlans again, the box sometimes paniced faster than I could fix my configuration. For the time being I'm back to 2.4GHz only (which worked for several days, as did 5GHz only - only the combination got my box panicing). Any ideas? Regards, Christoph -- Spare Space From owner-freebsd-stable@freebsd.org Sun Apr 1 22:00:08 2018 Return-Path: Delivered-To: freebsd-stable@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 C195FF7ED0F for ; Sun, 1 Apr 2018 22:00:08 +0000 (UTC) (envelope-from lists@knigma.org) Received: from shrewd.pub.knigma.org (shrewd.ipv6.pub.knigma.org [IPv6:2001:8b0:b0:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 438867FCD0 for ; Sun, 1 Apr 2018 22:00:08 +0000 (UTC) (envelope-from lists@knigma.org) Received: from dhcp13.wireless.knigma.org (localhost [127.0.0.1]) (authenticated bits=0) by shrewd.pub.knigma.org (8.15.2/8.15.2) with ESMTPSA id w31M059K007068 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 1 Apr 2018 23:00:05 +0100 (BST) (envelope-from lists@knigma.org) To: freebsd-stable@freebsd.org Reply-To: markk@knigma.org From: Mark Knight Subject: FreeBSD 10.4 kernel breaks on i7-7700 / PRIME H270M-PLUS Message-ID: Date: Sun, 1 Apr 2018 23:00:05 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (shrewd.pub.knigma.org [127.0.0.1]); Sun, 01 Apr 2018 23:00:05 +0100 (BST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 22:00:08 -0000 I'm trying to do the usual src code upgrade from FreeBSD 10.3 to 10.4, as I've done many times before with earlier version bumps. However, for some reason the 10.4 kernel seems to break my system, either with the 10.3 or 10.4 userland. The main issue seems to be some sort of deadlock. For example, on the console, following boot (which seems fairly normal) I can login to the console as root, but when I try to use commands like su or sudo to switch to another user, that command hangs and at that point CTRL-C is useless: I have to switch to another tty. Trying to login via ssh over the network also fails but neither case gives me any obvious clues in logs. If I switch back to a 10.3 kernel sanity is restored. Not sure if it's related, but on boot I see these new errors that weren't present on 10.3: > [1] ACPI Error: Mutex [0x0] is not acquired, cannot release (20160527/utmutex-386) > [1] ACPI Error: Could not release AML Interpreter mutex (20160527/exutils-147) > [1] ACPI Error: Mutex [0x0] is not acquired, cannot release (20160527/utmutex-386) > [1] ACPI Error: Could not release AML Interpreter mutex (20160527/exutils-147 I've dumped the kernel boot log here: http://www.knigma.org/scratch/010418.10.4.txt I'm struggling to pin down the cause, so I'm hoping this mail might jog a memory or provide a pointer please? Motherboard is a PRIME H270M-PLUS with the latest BIOS. Thanks!! -- Mark Knight From owner-freebsd-stable@freebsd.org Mon Apr 2 05:57:13 2018 Return-Path: Delivered-To: freebsd-stable@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 BA16DF74923 for ; Mon, 2 Apr 2018 05:57:13 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C5A26F282 for ; Mon, 2 Apr 2018 05:57:13 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w325v6xM004725 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 2 Apr 2018 07:57:06 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: markk@knigma.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w325v2AZ073901 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Apr 2018 12:57:02 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: FreeBSD 10.4 kernel breaks on i7-7700 / PRIME H270M-PLUS To: markk@knigma.org, freebsd-stable@freebsd.org References: From: Eugene Grosbein Message-ID: <5AC1C628.6030309@grosbein.net> Date: Mon, 2 Apr 2018 12:56:56 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 05:57:13 -0000 02.04.2018 5:00, Mark Knight wrote: > I'm trying to do the usual src code upgrade from FreeBSD 10.3 to 10.4, as I've done many times before with earlier version bumps. > > However, for some reason the 10.4 kernel seems to break my system, either with the 10.3 or 10.4 userland. > > The main issue seems to be some sort of deadlock. > For example, on the console, following boot (which seems fairly normal) > I can login to the console as root, but when I try to use commands like > su or sudo to switch to another user, that command hangs and at that point CTRL-C is useless: > I have to switch to another tty. What does it show if you press "CTRL-T" to see a status of "hung" process? Does it help if you comment out the line mentioning /dev/console in the /etc/syslog.conf and apply the change with killall -1 syslogd ? From owner-freebsd-stable@freebsd.org Mon Apr 2 12:27:16 2018 Return-Path: Delivered-To: freebsd-stable@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 A2AC6F51F59 for ; Mon, 2 Apr 2018 12:27:16 +0000 (UTC) (envelope-from lists@knigma.org) Received: from shrewd.pub.knigma.org (shrewd.ipv6.pub.knigma.org [IPv6:2001:8b0:b0:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 28CAD7C1C8 for ; Mon, 2 Apr 2018 12:27:15 +0000 (UTC) (envelope-from lists@knigma.org) Received: from dhcp13.wireless.knigma.org (localhost [127.0.0.1]) (authenticated bits=0) by shrewd.pub.knigma.org (8.15.2/8.15.2) with ESMTPSA id w32CRCs2001875 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 2 Apr 2018 13:27:12 +0100 (BST) (envelope-from lists@knigma.org) Reply-To: markk@knigma.org Subject: Re: FreeBSD 10.4 kernel breaks on i7-7700 / PRIME H270M-PLUS To: Eugene Grosbein , freebsd-stable@freebsd.org References: <5AC1C628.6030309@grosbein.net> From: Mark Knight Message-ID: <3c184bf8-8651-22a7-a040-8260b44647da@knigma.org> Date: Mon, 2 Apr 2018 13:27:12 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <5AC1C628.6030309@grosbein.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (shrewd.pub.knigma.org [127.0.0.1]); Mon, 02 Apr 2018 13:27:13 +0100 (BST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 12:27:16 -0000 On 02/04/2018 06:56, Eugene Grosbein wrote: > What does it show if you press "CTRL-T" to see a status of "hung" process? Typically CTRL-T shows [sysctl mem]. In some circumstances I can CTRL-C (e.g. if su hangs), in others I cannot (e.g. with sudo). > Does it help if you comment out the line mentioning /dev/console in the /etc/syslog.conf > and apply the change with killall -1 syslogd ? Doing that "killall -HUP syslogd" hangs with (sysctl mem) - as does "service syslogd restart" but after a fresh reboot, no - removing that line didn't help at all. Thanks for getting my hopes up :) Moving ~/myuser/.bashrc out of the way (it really doesn't contain much apart from setting a bunch of aliases), allows me to login as myself, but "sudo -u myuser -s" still hangs. I just got a truss output of "sudo -u myuser -s" per the file below, perhaps that contains a clue? # sudo -u myuser -s >& sudo.truss.log http://www.knigma.org/scratch/sudo.truss.log Flipping back to a 10.3 kernel makes everything happy (just as well, as the machine in question is my main router/firewall, so it's a right pain when it's not working). Thanks in advance for any fresh ideas; I'm really not sure where to go with this! -- Mark Knight From owner-freebsd-stable@freebsd.org Mon Apr 2 13:44:39 2018 Return-Path: Delivered-To: freebsd-stable@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 D6BB0F63B4E for ; Mon, 2 Apr 2018 13:44:38 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C70A7F4CC for ; Mon, 2 Apr 2018 13:44:38 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w32DiTx2007648 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 2 Apr 2018 15:44:29 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: markk@knigma.org Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTP id w32DiIEb079596; Mon, 2 Apr 2018 20:44:18 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: FreeBSD 10.4 kernel breaks on i7-7700 / PRIME H270M-PLUS To: markk@knigma.org, freebsd-stable@freebsd.org References: <5AC1C628.6030309@grosbein.net> <3c184bf8-8651-22a7-a040-8260b44647da@knigma.org> From: Eugene Grosbein X-Enigmail-Draft-Status: N1110 Message-ID: <5AC233B2.2050805@grosbein.net> Date: Mon, 2 Apr 2018 20:44:18 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <3c184bf8-8651-22a7-a040-8260b44647da@knigma.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=4.8 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * 2.6 DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-Spam-Level: **** X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 13:44:39 -0000 On 02.04.2018 19:27, Mark Knight wrote: >> What does it show if you press "CTRL-T" to see a status of "hung" process? > > Typically CTRL-T shows [sysctl mem]. In some circumstances I can CTRL-C > (e.g. if su hangs), in others I cannot (e.g. with sudo). > >> Does it help if you comment out the line mentioning /dev/console in the /etc/syslog.conf >> and apply the change with killall -1 syslogd ? > > Doing that "killall -HUP syslogd" hangs with (sysctl mem) - as does > "service syslogd restart" but after a fresh reboot, no - removing that > line didn't help at all. Thanks for getting my hopes up :) > > Moving ~/myuser/.bashrc out of the way (it really doesn't contain much > apart from setting a bunch of aliases), allows me to login as myself, > but "sudo -u myuser -s" still hangs. > > I just got a truss output of "sudo -u myuser -s" per the file below, > perhaps that contains a clue? > > # sudo -u myuser -s >& sudo.truss.log > > http://www.knigma.org/scratch/sudo.truss.log > > Flipping back to a 10.3 kernel makes everything happy (just as well, as > the machine in question is my main router/firewall, so it's a right pain > when it's not working). > > Thanks in advance for any fresh ideas; I'm really not sure where to go > with this! 1. Make sure you have kernel dumps enabled. Verify that dump can be properly generated and saved after reboot using "sysctl debug.kdb.panic=1" (this produced a panic). You should have crashdump in /var/crash after reboot. 2. Rebuild kernel using new updated sources but this time add to its config file: options KDB # Enable kernel debugger support. options KDB_UNATTENDED options KDB_TRACE options DDB # Support DDB. options GDB # Support remote GDB. options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed 3. Boot new kernel using nextboot(8) and see if it will crash instead of deadlock and if so, fill the PR to Bugzilla. From owner-freebsd-stable@freebsd.org Mon Apr 2 13:55:40 2018 Return-Path: Delivered-To: freebsd-stable@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 A742CF6B8E4 for ; Mon, 2 Apr 2018 13:55:40 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 27A5C7FD14 for ; Mon, 2 Apr 2018 13:55:39 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [194.32.164.27] ([194.32.164.27]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id w32DlosC068584 for ; Mon, 2 Apr 2018 14:47:50 +0100 (BST) (envelope-from rb@gid.co.uk) From: Bob Bishop Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: ZFS panic, ARC compression? Message-Id: Date: Mon, 2 Apr 2018 14:47:50 +0100 To: FreeBSD Stable X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 13:55:40 -0000 Hi, Anyone offer any suggestions about this? kernel: panic: solaris assert: arc_decompress(buf) =3D=3D 0 (0x5 =3D=3D = 0x0), file: = /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c, line: = 4923 kernel: cpuid =3D 1 kernel: KDB: stack backtrace: kernel: #0 0xffffffff80aadac7 at kdb_backtrace+0x67 kernel: #1 0xffffffff80a6bba6 at vpanic+0x186 kernel: #2 0xffffffff80a6ba13 at panic+0x43 kernel: #3 0xffffffff8248023c at assfail3+0x2c =20 kernel: #4 0xffffffff8218e2e0 at arc_read+0x9f0 =20 kernel: #5 0xffffffff82198e5e at dbuf_read+0x69e kernel: #6 0xffffffff821b3db4 at dnode_hold_impl+0x194 kernel: #7 0xffffffff821a11dd at dmu_bonus_hold+0x1d kernel: #8 0xffffffff8220fb05 at zfs_zget+0x65 kernel: #9 0xffffffff82227d42 at zfs_dirent_lookup+0x162 kernel: #10 0xffffffff82227e07 at zfs_dirlook+0x77 kernel: #11 0xffffffff8223fcea at zfs_lookup+0x44a =20 kernel: #12 0xffffffff822403fd at zfs_freebsd_lookup+0x6d kernel: #13 0xffffffff8104b963 at VOP_CACHEDLOOKUP_APV+0x83 kernel: #14 0xffffffff80b13816 at vfs_cache_lookup+0xd6 kernel: #15 0xffffffff8104b853 at VOP_LOOKUP_APV+0x83 kernel: #16 0xffffffff80b1d151 at lookup+0x701 =20 kernel: #17 0xffffffff80b1c606 at namei+0x486 Roughly 24 hours earlier (during the scrub), there was: ZFS: vdev state changed, pool_guid=3D11921811386284628759 = vdev_guid=3D1644286782598989949 ZFS: vdev state changed, pool_guid=3D11921811386284628759 = vdev_guid=3D17800276530669255627 % uname -a FreeBSD xxxxxxxxxxx 11.1-RELEASE-p4 FreeBSD 11.1-RELEASE-p4 #0: Tue Nov = 14 06:12:40 UTC 2017 = root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 % % zpool status pool: zroot state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://illumos.org/msg/ZFS-8000-8A scan: scrub repaired 15.7M in 2h37m with 1 errors on Sun Apr 1 = 09:44:39 2018 config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ada0p4 ONLINE 0 0 0 ada1p4 ONLINE 0 0 0 errors: 1 data errors, use '-v' for a list % The affected file (in a snapshot) is unimportant. This pool is a daily rsync backup and contains about 120 snapshots. No device or SMART errors were logged. -- Bob Bishop rb@gid.co.uk From owner-freebsd-stable@freebsd.org Mon Apr 2 16:41:33 2018 Return-Path: Delivered-To: freebsd-stable@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 09E92F765B0 for ; Mon, 2 Apr 2018 16:41:32 +0000 (UTC) (envelope-from lists@knigma.org) Received: from shrewd.pub.knigma.org (shrewd.ipv6.pub.knigma.org [IPv6:2001:8b0:b0:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0E1D8869A4 for ; Mon, 2 Apr 2018 16:41:31 +0000 (UTC) (envelope-from lists@knigma.org) Received: from dhcp13.wireless.knigma.org (localhost [127.0.0.1]) (authenticated bits=0) by shrewd.pub.knigma.org (8.15.2/8.15.2) with ESMTPSA id w32GfSKB001721 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 2 Apr 2018 17:41:29 +0100 (BST) (envelope-from lists@knigma.org) Reply-To: markk@knigma.org Subject: Re: FreeBSD 10.4 kernel breaks on i7-7700 / PRIME H270M-PLUS To: freebsd-stable@freebsd.org, Eugene Grosbein References: <5AC1C628.6030309@grosbein.net> <3c184bf8-8651-22a7-a040-8260b44647da@knigma.org> <5AC233B2.2050805@grosbein.net> From: Mark Knight Message-ID: <827319fc-b634-c0aa-063b-6e4a0ade8163@knigma.org> Date: Mon, 2 Apr 2018 17:41:28 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <5AC233B2.2050805@grosbein.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (shrewd.pub.knigma.org [127.0.0.1]); Mon, 02 Apr 2018 17:41:30 +0100 (BST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 16:41:33 -0000 On 02/04/2018 14:44, Eugene Grosbein wrote: > 3. Boot new kernel using nextboot(8) and see if it will crash instead of deadlock > and if so, fill the PR to Bugzilla. Thanks again. Drat, no crash. The only difference was a few new errors during the boot - which I'm assuming are unrelated. > Apr 2 17:27:58 shrewd kernel: [16] lock order reversal: > Apr 2 17:27:58 shrewd kernel: [16] 1st 0xfffff80077653418 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2253 > Apr 2 17:27:58 shrewd kernel: [16] 2nd 0xfffffe03dbe7d218 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:262 > Apr 2 17:27:58 shrewd kernel: [16] 3rd 0xfffff80077c089a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2253 > Apr 2 17:27:58 shrewd kernel: [16] KDB: stack backtrace: > Apr 2 17:27:58 shrewd kernel: [16] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0462049b30 > Apr 2 17:27:58 shrewd kernel: [16] kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0462049be0 > Apr 2 17:27:58 shrewd kernel: [16] witness_checkorder() at witness_checkorder+0xe2b/frame 0xfffffe0462049c70 > Apr 2 17:27:58 shrewd kernel: [16] __lockmgr_args() at __lockmgr_args+0x988/frame 0xfffffe0462049d90 > Apr 2 17:27:58 shrewd kernel: [16] ffs_lock() at ffs_lock+0x84/frame 0xfffffe0462049de0 > Apr 2 17:27:58 shrewd kernel: [16] VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfffffe0462 > Apr 2 17:27:58 shrewd kernel: 049e10 > Apr 2 17:27:59 shrewd kernel: [16] _vn_lock() at _vn_lock+0xaa/frame 0xfffffe0462049e80 > Apr 2 17:27:59 shrewd kernel: [16] vget() at vget+0x67/frame 0xfffffe0462049ec0 > Apr 2 17:27:59 shrewd kernel: [16] vfs_hash_get() at vfs_hash_get+0xe1/frame 0xfffffe0462049f10 > Apr 2 17:27:59 shrewd kernel: [16] ffs_vgetf() at ffs_vgetf+0x40/frame 0xfffffe0462049fa0 > Apr 2 17:27:59 shrewd kernel: [16] softdep_sync_buf() at softdep_sync_buf+0xa25/frame 0xfffffe046204a090 > Apr 2 17:27:59 shrewd kernel: [16] ffs_syncvnode() at ffs_syncvnode+0x286/frame 0xfffffe046204a110 > Apr 2 17:27:59 shrewd kernel: [16] ffs_truncate() at ffs_truncate+0x6a9/frame 0xfffffe046204a2f0 > Apr 2 17:27:59 shrewd kernel: [16] ufs_direnter() at ufs_direnter+0x7c8/frame 0xfffffe046204a3b0 > Apr 2 17:27:59 shrewd kernel: [16] ufs_makeinode() at ufs_makeinode+0x5d9/frame 0xfffffe046204a570 > Apr 2 17:27:59 shrewd kernel: [16] ufs_create() at ufs_create+0x34/frame 0xfffffe046204a590 > Apr 2 17:27:59 shrewd kernel: [16] VOP_CREATE_APV() at VOP_CREATE_APV+0xf1/frame 0xfffffe046204a5c0 > Apr 2 17:27:59 shrewd kernel: [16] vn_open_cred() at vn_open_cred+0x2c3/frame 0xfffffe046204a720 > Apr 2 17:27:59 shrewd kernel: [16] kern_openat() at kern_openat+0x26f/frame 0xfffffe046204a8a0 > Apr 2 17:27:59 shrewd kernel: [16] amd64_syscall() at amd64_syscall+0x2c6/frame 0xfffffe046204a9b0 > Apr 2 17:27:59 shrewd kernel: [16] Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe046204a9b0 > Apr 2 17:27:59 shrewd kernel: [16] --- syscall (5, FreeBSD ELF64, sys_open), rip = 0x801fcc9aa, rsp = 0x7fffdfdf9c38, rbp = 0x7fffdfdf9c60 --- > Apr 2 17:28:48 shrewd kernel: [66] lock order reversal: > Apr 2 17:28:48 shrewd kernel: [66] 1st 0xfffffe03dbf949f8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3130 > Apr 2 17:28:48 shrewd kernel: [66] 2nd 0xfffff8000b741000 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:280 > Apr 2 17:28:48 shrewd kernel: [66] KDB: stack backtrace: > Apr 2 17:28:48 shrewd kernel: [66] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0462185130 > Apr 2 17:28:48 shrewd kernel: [66] kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe04621851e0 > Apr 2 17:28:48 shrewd kernel: [66] witness_checkorder() at witness_checkorder+0xe2b/frame 0xfffffe0462185270 > Apr 2 17:28:48 shrewd kernel: [66] _sx_xlock() at _sx_xlock+0x75/frame 0xfffffe04621852b0 > Apr 2 17:28:48 shrewd kernel: [66] ufsdirhash_add() at ufsdirhash_add+0x3a/frame 0xfffffe04621852f0 > Apr 2 17:28:48 shrewd kernel: [66] ufs_direnter() at ufs_direnter+0x622/frame 0xfffffe04621853b0 > Apr 2 17:28:48 shrewd kernel: [66] ufs_makeinode() at ufs_makeinode+0x5d9/frame 0xfffffe0462185570 > Apr 2 17:28:48 shrewd kernel: [66] ufs_create() at ufs_create+0x34/frame 0xfffffe0462185590 > Apr 2 17:28:48 shrewd kernel: [66] VOP_CREATE_APV() at VOP_CREATE_APV+0xf1/frame 0xfffffe04621855c0 > Apr 2 17:28:48 shrewd kernel: [66] vn_open_cred() at vn_open_cred+0x2c3/frame 0xfffffe0462185720 > Apr 2 17:28:48 shrewd kernel: [66] kern_openat() at kern_openat+0x26f/frame 0xfffffe04621858a0 > Apr 2 17:28:48 shrewd kernel: [66] amd64_syscall() at amd64_syscall+0x2c6/frame 0xfffffe04621859b0 > Apr 2 17:28:48 shrewd kernel: [66] Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe04621859b0 > Apr 2 17:28:48 shrewd kernel: [66] --- syscall (499, FreeBSD ELF64, sys_openat), rip = 0x80174cb7a, rsp = 0x7fffffff7f58, rbp = 0x7fffffff7fd0 --- -- Mark Knight From owner-freebsd-stable@freebsd.org Mon Apr 2 17:35:58 2018 Return-Path: Delivered-To: freebsd-stable@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 3C0EAF79EF8 for ; Mon, 2 Apr 2018 17:35:58 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B09BE68CF5 for ; Mon, 2 Apr 2018 17:35:57 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w32HZi9x009047 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 2 Apr 2018 19:35:44 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: markk@knigma.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w32HZeWd081034 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 3 Apr 2018 00:35:40 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: FreeBSD 10.4 kernel breaks on i7-7700 / PRIME H270M-PLUS To: markk@knigma.org, freebsd-stable@freebsd.org References: <5AC1C628.6030309@grosbein.net> <3c184bf8-8651-22a7-a040-8260b44647da@knigma.org> <5AC233B2.2050805@grosbein.net> <827319fc-b634-c0aa-063b-6e4a0ade8163@knigma.org> From: Eugene Grosbein Message-ID: <5AC269E7.6030100@grosbein.net> Date: Tue, 3 Apr 2018 00:35:35 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <827319fc-b634-c0aa-063b-6e4a0ade8163@knigma.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 17:35:58 -0000 02.04.2018 23:41, Mark Knight пишет: > On 02/04/2018 14:44, Eugene Grosbein wrote: >> 3. Boot new kernel using nextboot(8) and see if it will crash instead of deadlock >> and if so, fill the PR to Bugzilla. > > Thanks again. Drat, no crash. The only difference was a few new errors during the boot - which I'm assuming are unrelated. Add to /etc/sysctl.conf: debug.kdb.break_to_debugger=1 Use such debugging kernel to drop to the debugger when deadlock occurs using Ctr-Alt-ESC and type "call doadump", you should get crashdump anyway. Then use "reboot" or just power cycle to get crashdump stored to /var/crash. Then fill a PR and reply with the number. From owner-freebsd-stable@freebsd.org Mon Apr 2 20:50:23 2018 Return-Path: Delivered-To: freebsd-stable@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 8D83FF84662 for ; Mon, 2 Apr 2018 20:50:23 +0000 (UTC) (envelope-from lists@knigma.org) Received: from shrewd.pub.knigma.org (shrewd.ipv6.pub.knigma.org [IPv6:2001:8b0:b0:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1203E71625 for ; Mon, 2 Apr 2018 20:50:22 +0000 (UTC) (envelope-from lists@knigma.org) Received: from dhcp13.wireless.knigma.org (localhost [127.0.0.1]) (authenticated bits=0) by shrewd.pub.knigma.org (8.15.2/8.15.2) with ESMTPSA id w32KoJxI003277 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 2 Apr 2018 21:50:21 +0100 (BST) (envelope-from lists@knigma.org) Reply-To: markk@knigma.org Subject: Re: FreeBSD 10.4 kernel breaks on i7-7700 / PRIME H270M-PLUS To: freebsd-stable@freebsd.org, Eugene Grosbein References: <5AC1C628.6030309@grosbein.net> <3c184bf8-8651-22a7-a040-8260b44647da@knigma.org> <5AC233B2.2050805@grosbein.net> <827319fc-b634-c0aa-063b-6e4a0ade8163@knigma.org> <5AC269E7.6030100@grosbein.net> From: Mark Knight Message-ID: <1b17100b-0f20-9de4-747c-534d52550bb9@knigma.org> Date: Mon, 2 Apr 2018 21:50:19 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <5AC269E7.6030100@grosbein.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (shrewd.pub.knigma.org [127.0.0.1]); Mon, 02 Apr 2018 21:50:21 +0100 (BST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 20:50:23 -0000 On 02/04/2018 18:35, Eugene Grosbein wrote: > Use such debugging kernel to drop to the debugger when deadlock occurs > using Ctr-Alt-ESC and type "call doadump", you should get crashdump anyway. > Then use "reboot" or just power cycle to get crashdump stored to /var/crash. > > Then fill a PR and reply with the number. Thank you. Please see: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227213 Hopefully I've provided links to the necessary files. Let me know if anything else is useful! Best regards, Mark -- Mark Knight From owner-freebsd-stable@freebsd.org Mon Apr 2 22:05:12 2018 Return-Path: Delivered-To: freebsd-stable@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 7A037F4FBBB for ; Mon, 2 Apr 2018 22:05:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 11FA874E4A for ; Mon, 2 Apr 2018 22:05:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 4A7DC12124 for ; Mon, 2 Apr 2018 22:05:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w32M5B6e068271 for ; Mon, 2 Apr 2018 22:05:11 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w32M5BPM068270 for freebsd-stable@FreeBSD.org; Mon, 2 Apr 2018 22:05:11 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 227213] FreeBSD 10.4 kernel deadlocks on sysctlmemlock Date: Mon, 02 Apr 2018 22:05:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.4-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-stable@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 22:05:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227213 Eugene Grosbein changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-stable@FreeBSD.org Summary|FreeBSD 10.4 kernel |FreeBSD 10.4 kernel |deadlocks with i7-7700 / |deadlocks on sysctlmemlock |ASUS PRIME H270M-PLUS | --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-stable@freebsd.org Tue Apr 3 15:58:21 2018 Return-Path: Delivered-To: freebsd-stable@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 17815F5323F for ; Tue, 3 Apr 2018 15:58:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A9F41841C8 for ; Tue, 3 Apr 2018 15:58:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id D61931B630 for ; Tue, 3 Apr 2018 15:58:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w33FwJ2U025408 for ; Tue, 3 Apr 2018 15:58:19 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w33FwJ2e025407 for freebsd-stable@FreeBSD.org; Tue, 3 Apr 2018 15:58:19 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 227213] FreeBSD 10.4 kernel deadlocks on sysctlmemlock Date: Tue, 03 Apr 2018 15:58:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.4-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-stable@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 15:58:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227213 --- Comment #8 from Eugene Grosbein --- Created attachment 192172 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D192172&action= =3Dedit some debug info for snmpd from the crashdump Note that snmpd is hung on sx_xlock() with insanely large req.validlen =3D= =3D 140737488349408 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-stable@freebsd.org Tue Apr 3 18:04:26 2018 Return-Path: Delivered-To: freebsd-stable@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 69BD0F73B36 for ; Tue, 3 Apr 2018 18:04:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 071136A4EF for ; Tue, 3 Apr 2018 18:04:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 3916B1C838 for ; Tue, 3 Apr 2018 18:04:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w33I4PN6063255 for ; Tue, 3 Apr 2018 18:04:25 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w33I4Ptn063254 for freebsd-stable@FreeBSD.org; Tue, 3 Apr 2018 18:04:25 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 227213] FreeBSD 10.4 kernel deadlocks on sysctlmemlock Date: Tue, 03 Apr 2018 18:04:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.4-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markk@knigma.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-stable@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 18:04:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227213 --- Comment #9 from Mark Knight --- You asked: > What do you use vm.defer_swapspace_pageouts=3D1 for? After moving existing disks to a new chassis I have more RAM than swap and repartitioning would be a pain - I really don't need 16GB of swap! Without = this sysctl I was finding my swap was becoming full and lots of associated "out = of swap space" error. Since adding this sysctl that problem as ceased. I hope = 11.x won't have the same problem... As requested, here's a fresh kernel dump created as follows: 1) Disabled snmpd and snmptrapd in /etc/rc.conf, so definitely no snmpd running 2) reboot with 10.4 kernel 3) Login to console as root 4) Type ps 5) Deadlock occurs 6) CTRL-T shows [sysctl-mem] 7) Ctrl-Alt-ESC followed by call doadump http://www.knigma.org/scratch/core.txt.1 http://www.knigma.org/scratch/vmcore.1.gz Kernel is the same file as before, so no need to download that again! Many thanks!! --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-stable@freebsd.org Tue Apr 3 18:14:36 2018 Return-Path: Delivered-To: freebsd-stable@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 3D9C9F74756 for ; Tue, 3 Apr 2018 18:14:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C2E856AC26 for ; Tue, 3 Apr 2018 18:14:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 052591C991 for ; Tue, 3 Apr 2018 18:14:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w33IEYic071336 for ; Tue, 3 Apr 2018 18:14:34 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w33IEYCx071332 for freebsd-stable@FreeBSD.org; Tue, 3 Apr 2018 18:14:34 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 227213] FreeBSD 10.4 kernel deadlocks on sysctlmemlock Date: Tue, 03 Apr 2018 18:14:35 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.4-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markk@knigma.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-stable@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 18:14:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227213 --- Comment #10 from Mark Knight --- As suggested, I just tried commenting out vm.defer_swapspace_pageouts=3D1. Commenting it out from /etc/sysctl.conf didn't make any difference, 10.4 st= ill deadlocks. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-stable@freebsd.org Tue Apr 3 19:32:45 2018 Return-Path: Delivered-To: freebsd-stable@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 6924CF79A6D for ; Tue, 3 Apr 2018 19:32:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 023966ED1F for ; Tue, 3 Apr 2018 19:32:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 3FF4D1D4C5 for ; Tue, 3 Apr 2018 19:32:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w33JWitZ049149 for ; Tue, 3 Apr 2018 19:32:44 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w33JWiTZ049146 for freebsd-stable@FreeBSD.org; Tue, 3 Apr 2018 19:32:44 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 227213] FreeBSD 10.4 kernel deadlocks on sysctlmemlock Date: Tue, 03 Apr 2018 19:32:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.4-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-stable@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 19:32:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227213 --- Comment #11 from Eugene Grosbein --- (In reply to Mark Knight from comment #9) What is UID 104 here? It seems it is used for some perl process that may be triggering the problem and not snmpd. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-stable@freebsd.org Tue Apr 3 21:10:31 2018 Return-Path: Delivered-To: freebsd-stable@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 1F483F80D77 for ; Tue, 3 Apr 2018 21:10:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B0D9274C0E for ; Tue, 3 Apr 2018 21:10:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id E1D4A1E11B for ; Tue, 3 Apr 2018 21:10:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w33LATt4065986 for ; Tue, 3 Apr 2018 21:10:29 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w33LATSn065979 for freebsd-stable@FreeBSD.org; Tue, 3 Apr 2018 21:10:29 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 227213] FreeBSD 10.4 kernel deadlocks on sysctlmemlock Date: Tue, 03 Apr 2018 21:10:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.4-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markk@knigma.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-stable@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 21:10:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227213 --- Comment #12 from Mark Knight --- UID 104 is: slimserv:*:104:104:Slim Devices SlimServer pseudo-user:/nonexistent:/usr/sbin/nologin ps (on a working kernel), shows: slimserv 1117 0.0 0.9 253920 147596 - Ss 7:13PM 0:15.34 /usr/local/bin/perl /usr/local/share/logitechmediaserver/slimserver.pl --da= emon --pidfile=3D/var/run/logitechmediaserver/logitechmediaserver.pid --user=3Ds= limserv --group=3Dslimserv This is logitechmediaserver-7.9.1.g2017.07.11, from /usr/ports/audio/logitechmediaserver I'm surprised that's mischievous - it's just a music server, but I'll try disabling it in a moment and seeing if that helps :) The only other perl I have running as a daemon is mrtg-2.17.4_7,1 from /usr/ports/net-mgmt/mrtg. I should mention that all my ports are up-to-date. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-stable@freebsd.org Tue Apr 3 21:25:14 2018 Return-Path: Delivered-To: freebsd-stable@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 966F3F81E65 for ; Tue, 3 Apr 2018 21:25:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 18B4975CBC for ; Tue, 3 Apr 2018 21:25:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 57E521E3E0 for ; Tue, 3 Apr 2018 21:25:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w33LPDWZ005222 for ; Tue, 3 Apr 2018 21:25:13 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w33LPDut005220 for freebsd-stable@FreeBSD.org; Tue, 3 Apr 2018 21:25:13 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 227213] FreeBSD 10.4 kernel deadlocks on sysctlmemlock Date: Tue, 03 Apr 2018 21:25:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.4-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markk@knigma.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-stable@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 21:25:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227213 --- Comment #13 from Mark Knight --- I just tried disabling logitechmediaserver and restarting. Didn't help. The= n I disabled mrtg and restarted. Still didn't help. Here's a fresh dump with neither running. Same repo steps (root login follo= wed by ps) and same symptoms. http://www.knigma.org/scratch/core.txt.2 http://www.knigma.org/scratch/vmcore.2.gz Incidentally, ps works in single user mode, but it would be very tedious to= do a binary chop to find what's tickling the problem --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-stable@freebsd.org Wed Apr 4 01:13:30 2018 Return-Path: Delivered-To: freebsd-stable@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 EF237F82A94 for ; Wed, 4 Apr 2018 01:13:29 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61E367F710 for ; Wed, 4 Apr 2018 01:13:25 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.sub.de (8.15.2/8.15.2) with ESMTPS id w341D7LL038753 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 4 Apr 2018 03:13:08 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.15.2/8.15.2/Submit) with UUCP id w341D732038752 for freebsd-stable@FreeBSD.ORG; Wed, 4 Apr 2018 03:13:07 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id w34166fj010958 for ; Wed, 4 Apr 2018 03:06:06 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id w34142Xl010690 for ; Wed, 4 Apr 2018 03:04:02 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id w341424f010683 for freebsd-stable@FreeBSD.ORG; Wed, 4 Apr 2018 03:04:02 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: kern.sched.quantum: Creepy, sadistic scheduler Date: Wed, 4 Apr 2018 02:52:55 +0200 Organization: even some more stinky socks Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 4 Apr 2018 00:53:27 -0000 (UTC) Injection-Info: oper.dinoex.de; logging-data="8285"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48 X-Mozilla-News-Host: news://localhost:119 Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.sub.de [194.45.71.2]); Wed, 04 Apr 2018 03:13:09 +0200 (CEST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 01:13:30 -0000 Occasionally I noticed that the system would not quickly process the tasks i need done, but instead prefer other, longrunning tasks. I figured it must be related to the scheduler, and decided it hates me. A closer look shows the behaviour as follows (single CPU): Lets run an I/O-active task, e.g, postgres VACUUM that would continuousely read from big files (while doing compute as well [1]): >pool alloc free read write read write >cache - - - - - - > ada1s4 7.08G 10.9G 1.58K 0 12.9M 0 Now start an endless loop: # while true; do :; done And the effect is: >pool alloc free read write read write >cache - - - - - - > ada1s4 7.08G 10.9G 9 0 76.8K 0 The VACUUM gets almost stuck! This figures with WCPU in "top": > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND >85583 root 99 0 7044K 1944K RUN 1:06 92.21% bash >53005 pgsql 52 0 620M 91856K RUN 5:47 0.50% postgres Hacking on kern.sched.quantum makes it quite a bit better: # sysctl kern.sched.quantum=1 kern.sched.quantum: 94488 -> 7874 >pool alloc free read write read write >cache - - - - - - > ada1s4 7.08G 10.9G 395 0 3.12M 0 > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND >85583 root 94 0 7044K 1944K RUN 4:13 70.80% bash >53005 pgsql 52 0 276M 91856K RUN 5:52 11.83% postgres Now, as usual, the "root-cause" questions arise: What exactly does this "quantum"? Is this solution a workaround, i.e. actually something else is wrong, and has it tradeoff in other situations? Or otherwise, why is such a default value chosen, which appears to be ill-deceived? The docs for the quantum parameter are a bit unsatisfying - they say its the max num of ticks a process gets - and what happens when they're exhausted? If by default the endless loop is actually allowed to continue running for 94k ticks (or 94ms, more likely) uninterrupted, then that explains the perceived behaviour - buts thats certainly not what a scheduler should do when other procs are ready to run. 11.1-RELEASE-p7, kern.hz=200. Switching tickless mode on or off does not influence the matter. Starting the endless loop with "nice" does not influence the matter. [1] A pure-I/O job without compute load, like "dd", does not show this behaviour. Also, when other tasks are running, the unjust behaviour is not so stongly pronounced. From owner-freebsd-stable@freebsd.org Wed Apr 4 06:48:00 2018 Return-Path: Delivered-To: freebsd-stable@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 759A5F961B9 for ; Wed, 4 Apr 2018 06:48:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BD0B8E555 for ; Wed, 4 Apr 2018 06:48:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 3DEC623024 for ; Wed, 4 Apr 2018 06:47:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w346lxHT031076 for ; Wed, 4 Apr 2018 06:47:59 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w346lxJt031075 for freebsd-stable@FreeBSD.org; Wed, 4 Apr 2018 06:47:59 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 227213] FreeBSD 10.4 kernel deadlocks on sysctlmemlock Date: Wed, 04 Apr 2018 06:47:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.4-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-stable@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 06:48:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227213 --- Comment #14 from Eugene Grosbein --- (In reply to Mark Knight from comment #13) Do you use GENERIC kernel? If not, please attach your kernel config file. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-stable@freebsd.org Wed Apr 4 07:21:18 2018 Return-Path: Delivered-To: freebsd-stable@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 785EAF9931B for ; Wed, 4 Apr 2018 07:21:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1176268939 for ; Wed, 4 Apr 2018 07:21:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 3E0462358A for ; Wed, 4 Apr 2018 07:21:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w347LHGj025556 for ; Wed, 4 Apr 2018 07:21:17 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w347LHv1025555 for freebsd-stable@FreeBSD.org; Wed, 4 Apr 2018 07:21:17 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-stable@FreeBSD.org Subject: [Bug 227213] FreeBSD 10.4 kernel deadlocks on sysctlmemlock Date: Wed, 04 Apr 2018 07:21:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.4-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markk@knigma.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-stable@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 07:21:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227213 --- Comment #15 from Mark Knight --- Created attachment 192199 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D192199&action= =3Dedit Kernel config file Attached kernel config. My kernel is close to generic, extras are: > options IPFIREWALL > options IPDIVERT > options DUMMYNET then added these for debug, but the problem occurred without them: > options KDB_UNATTENDED > options DDB # Support DDB. > options GDB # Support remote GDB. > options INVARIANTS # Enable calls of extra sanity ch= ecking > options INVARIANT_SUPPORT # Extra sanity checks of internal= structures, required by INVARIANTS > options WITNESS # Enable checks to detect deadloc= ks and cycles > options WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed You've probably got these from loader.conf, but I also have these: mkn@shrewd$ kldstat Id Refs Address Size Name 1 35 0xffffffff80200000 17dbb70 kernel 2 1 0xffffffff819dc000 215a8 geom_eli.ko 3 2 0xffffffff819fe000 352d0 crypto.ko 4 1 0xffffffff81a34000 23fb0 geom_mirror.ko 5 1 0xffffffff81a58000 157c0 aio.ko 6 1 0xffffffff81a6e000 4a70 coretemp.ko 7 1 0xffffffff81a73000 b188 sem.ko 8 1 0xffffffff81a7f000 26e0 cc_cubic.ko 9 1 0xffffffff81c11000 56c6 fdescfs.ko 10 1 0xffffffff81c17000 8df4 uftdi.ko 11 1 0xffffffff81c20000 54c4 ucom.ko 12 1 0xffffffff81c26000 3d12c linux.ko 13 2 0xffffffff81c64000 683b linux_common.ko 14 1 0xffffffff81c6b000 37ae9 linux64.ko --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-stable@freebsd.org Wed Apr 4 07:22:01 2018 Return-Path: Delivered-To: freebsd-stable@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 A8933F993B7 for ; Wed, 4 Apr 2018 07:22:01 +0000 (UTC) (envelope-from eugene@zhegan.in) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2111F68A2B for ; Wed, 4 Apr 2018 07:22:00 +0000 (UTC) (envelope-from eugene@zhegan.in) Received: from bsdrookie.norma.com. (asterisk.enaza.ru [91.237.76.254]) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPS id w347LpMD024425 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 4 Apr 2018 12:21:51 +0500 (YEKT) (envelope-from eugene@zhegan.in) To: freebsd-stable@FreeBSD.org From: "Eugene M. Zheganin" Subject: another question about zfs compression numbers Message-ID: <52b1c557-bdb5-3b9f-1ce1-32f698ae982c@zhegan.in> Date: Wed, 4 Apr 2018 12:21:51 +0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spamd-Result: default: False [-998.10 / 25.00] WHITELISTED_IPS(-999.00)[91.237.76.254] AUTH_NA(1.00)[] RCVD_COUNT_TWO(0.00)[2] MID_RHS_MATCH_FROM(0.00)[] DMARC_NA(0.00)[zhegan.in] FROM_EQ_ENVFROM(0.00)[] ARC_NA(0.00)[] ASN(0.00)[asn:57973, ipnet:91.237.76.0/24, country:RU] FROM_HAS_DN(0.00)[] R_SPF_NA(0.00)[] TO_MATCH_ENVRCPT_ALL(0.00)[] TO_DN_NONE(0.00)[] MIME_GOOD(-0.10)[text/plain] RCPT_COUNT_ONE(0.00)[1] RCVD_TLS_ALL(0.00)[] R_DKIM_NA(0.00)[] IP_SCORE(0.00)[ip: (-9.88), ipnet: 91.237.76.0/24(-7.81), asn: 57973(-4.88), country: RU(0.12)] X-Rspamd-Server: localhost X-Rspamd-Scan-Time: 2.73 X-Rspamd-Queue-ID: w347LpMD024425 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 07:22:01 -0000 Hello, I'm just trying to understand these numbers: file size is 232G, it's actual size on the lz4-compressed dataset is 18G, so then why is the compressratio only 1.86x ? And why logicalused is 34.2G ? On one hand, 34.2G exactlyfits to the 1.86x compresstaio, but still I don't get it. dataset is on raidz, 3 spans across 5 disk vdevs, with total of 15 disks if it matters: # du -h 18G . # ls -lh total 19316318 -rw-r----- 1 root wheel 232G 4 ÁÐÒ. 11:29 mp_userCoordsHistory.ibd # zfs get all data/test NAME PROPERTY VALUE SOURCE data/test type filesystem - data/test creation ÓÒ ÁÐÒ. 4 10:31 2018 - data/test used 18,4G - data/test available 9,95T - data/test referenced 18,4G - data/test compressratio 1.86x - data/test mounted yes - data/test quota none default data/test reservation none default data/test recordsize 128K default data/test mountpoint /data/test default data/test sharenfs off default data/test checksum on default data/test compression lz4 local data/test atime on default data/test devices on default data/test exec on default data/test setuid on default data/test readonly off default data/test jailed off default data/test snapdir hidden default data/test aclmode discard default data/test aclinherit restricted default data/test canmount on default data/test xattr off temporary data/test copies 1 default data/test version 5 - data/test utf8only off - data/test normalization none - data/test casesensitivity sensitive - data/test vscan off default data/test nbmand off default data/test sharesmb off default data/test refquota none default data/test refreservation none default data/test primarycache all default data/test secondarycache all default data/test usedbysnapshots 0 - data/test usedbydataset 18,4G - data/test usedbychildren 0 - data/test usedbyrefreservation 0 - data/test logbias latency default data/test dedup on inherited from data data/test mlslabel - data/test sync standard default data/test refcompressratio 1.86x - data/test written 18,4G - data/test logicalused 34,2G - data/test logicalreferenced 34,2G - data/test volmode default default data/test filesystem_limit none default data/test snapshot_limit none default data/test filesystem_count none default data/test snapshot_count none default data/test redundant_metadata all default # zpool status pool: data state: ONLINE scan: scrub repaired 0 in 28h24m with 0 errors on Thu Feb 15 13:26:36 2018 config: NAME STATE READ WRITE CKSUM data ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 da2 ONLINE 0 0 0 da3 ONLINE 0 0 0 da4 ONLINE 0 0 0 da5 ONLINE 0 0 0 da6 ONLINE 0 0 0 raidz1-1 ONLINE 0 0 0 da7 ONLINE 0 0 0 da8 ONLINE 0 0 0 da9 ONLINE 0 0 0 da10 ONLINE 0 0 0 da11 ONLINE 0 0 0 raidz1-2 ONLINE 0 0 0 da12 ONLINE 0 0 0 da13 ONLINE 0 0 0 da14 ONLINE 0 0 0 da15 ONLINE 0 0 0 da16 ONLINE 0 0 0 From owner-freebsd-stable@freebsd.org Wed Apr 4 07:41:00 2018 Return-Path: Delivered-To: freebsd-stable@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 3EE69F9A9AC for ; Wed, 4 Apr 2018 07:41:00 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BA054694E9 for ; Wed, 4 Apr 2018 07:40:59 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [217.29.44.10]) by gate2.intern.punkt.de with ESMTP id w347ZWjC098324; Wed, 4 Apr 2018 09:35:32 +0200 (CEST) Received: from [217.29.44.241] ([217.29.44.241]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id w347ZUK4027602; Wed, 4 Apr 2018 09:35:31 +0200 (CEST) (envelope-from hausen@punkt.de) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: another question about zfs compression numbers From: "Patrick M. Hausen" In-Reply-To: <52b1c557-bdb5-3b9f-1ce1-32f698ae982c@zhegan.in> Date: Wed, 4 Apr 2018 09:35:30 +0200 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8A5C86CA-C959-4DFF-9168-DD94CF46AC91@punkt.de> References: <52b1c557-bdb5-3b9f-1ce1-32f698ae982c@zhegan.in> To: "Eugene M. Zheganin" X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 07:41:00 -0000 Hi all, > Am 04.04.2018 um 09:21 schrieb Eugene M. Zheganin : > I'm just trying to understand these numbers: >=20 > file size is 232G, it's actual size on the lz4-compressed dataset is = 18G, so then why is the compressratio only 1.86x ? And why logicalused = is 34.2G ? On one hand, 34.2G exactlyfits to the 1.86x compresstaio, but = still I don't get it. dataset is on raidz, 3 spans across 5 disk vdevs, = with total of 15 disks if it matters: A sparse file, possibly? The ZFS numbers refer to blocks. "Skipping" = zeroes at the VFS layer is not taken into account as fas as I know. Seriously, how = should it? If I'm not mistaken, ZFS will never get to see these empty blocks. Patrick --=20 punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe info@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling From owner-freebsd-stable@freebsd.org Wed Apr 4 07:46:38 2018 Return-Path: Delivered-To: freebsd-stable@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 E9CA1F9AEFB for ; Wed, 4 Apr 2018 07:46:37 +0000 (UTC) (envelope-from eugene@zhegan.in) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F9E0699CD for ; Wed, 4 Apr 2018 07:46:37 +0000 (UTC) (envelope-from eugene@zhegan.in) Received: from bsdrookie.norma.com. (asterisk.enaza.ru [91.237.76.254]) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPS id w347kXde025317 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 4 Apr 2018 12:46:33 +0500 (YEKT) (envelope-from eugene@zhegan.in) Subject: Re: another question about zfs compression numbers To: "Patrick M. Hausen" Cc: freebsd-stable@freebsd.org References: <52b1c557-bdb5-3b9f-1ce1-32f698ae982c@zhegan.in> <8A5C86CA-C959-4DFF-9168-DD94CF46AC91@punkt.de> From: "Eugene M. Zheganin" Message-ID: <60635355-c0f3-9c3e-2375-7637bb073d87@zhegan.in> Date: Wed, 4 Apr 2018 12:46:33 +0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <8A5C86CA-C959-4DFF-9168-DD94CF46AC91@punkt.de> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spamd-Result: default: False [-998.10 / 25.00] WHITELISTED_IPS(-999.00)[91.237.76.254] AUTH_NA(1.00)[] RCVD_COUNT_TWO(0.00)[2] MID_RHS_MATCH_FROM(0.00)[] DMARC_NA(0.00)[zhegan.in] FROM_EQ_ENVFROM(0.00)[] ARC_NA(0.00)[] ASN(0.00)[asn:57973, ipnet:91.237.76.0/24, country:RU] FROM_HAS_DN(0.00)[] R_SPF_NA(0.00)[] TO_MATCH_ENVRCPT_ALL(0.00)[] MIME_GOOD(-0.10)[text/plain] RCVD_TLS_ALL(0.00)[] RCPT_COUNT_TWO(0.00)[2] TO_DN_SOME(0.00)[] R_DKIM_NA(0.00)[] IP_SCORE(0.00)[ip: (-9.88), ipnet: 91.237.76.0/24(-7.81), asn: 57973(-4.88), country: RU(0.12)] X-Rspamd-Server: localhost X-Rspamd-Scan-Time: 0.63 X-Rspamd-Queue-ID: w347kXde025317 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 07:46:38 -0000 Hi, On 04.04.2018 12:35, Patrick M. Hausen wrote: > Hi all, > >> Am 04.04.2018 um 09:21 schrieb Eugene M. Zheganin : >> I'm just trying to understand these numbers: >> >> file size is 232G, it's actual size on the lz4-compressed dataset is 18G, so then why is the compressratio only 1.86x ? And why logicalused is 34.2G ? On one hand, 34.2G exactlyfits to the 1.86x compresstaio, but still I don't get it. dataset is on raidz, 3 spans across 5 disk vdevs, with total of 15 disks if it matters: > A sparse file, possibly? The ZFS numbers refer to blocks. "Skipping" zeroes at the > VFS layer is not taken into account as fas as I know. Seriously, how should it? > If I'm not mistaken, ZFS will never get to see these empty blocks. > Looks so, thanks. Although it's a mysql tablespace file. But yeah, in hex viewer looks like it's filled with zeroes in many places. Eugene. From owner-freebsd-stable@freebsd.org Wed Apr 4 10:39:28 2018 Return-Path: Delivered-To: freebsd-stable@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 AAE8CF8254E for ; Wed, 4 Apr 2018 10:39:28 +0000 (UTC) (envelope-from haramrae@gmail.com) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 36436716D3 for ; Wed, 4 Apr 2018 10:39:28 +0000 (UTC) (envelope-from haramrae@gmail.com) Received: by mail-wm0-x22f.google.com with SMTP id r191so8963689wmg.4 for ; Wed, 04 Apr 2018 03:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5tghv9bmtJmabjMfN2bVkEGTNkGOIp9h7iCJQvxUJYQ=; b=LnjYS/qwWmHtxm1KFljilagifcbts1w/ZD+FcgiU9n2jPHST9peeP2zQomBxo8eWvu zdrWZZGp8uzumsUWhqdcyOZSN4wKW3Heqr6ZiYlhK2Z59syT0SMQCVvjgsfs3VBSMoMV k79TWQqnNFZNOxyLJpejpwgE1BYUeghT5IG0/XGY0W4rrzc2kco3ArowtzwVQenp8oFu Bpuj6jICTbeIuteJZNwEuiyJ3TM0+Aj9nMeaR/RdBlkVKDPfuQBwbEIsKHw3nRjLlIHS e6YzAKZ45juEqdte2l8UG8H+vAqVxMInAMayMOiInHVyLsMZp7Ap/jAjRtuUflVqXz2Y uZVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5tghv9bmtJmabjMfN2bVkEGTNkGOIp9h7iCJQvxUJYQ=; b=ei6PIvJjMJHngHepiLLPRkwUxCZtS9lVL2vrtd7iyfJj04puFWO+UbFr5onO7VoeW3 vAPvfElcLSQDKI0B3hEd75O1ZkX0ifZU8riD+1up1j3M1jnsIeWo8SHq3rjeUK1Ih8SB ncVXR6UsrEY4d1J6p+alg9Rq5l4au2Thp+vARayTHXrNm24Q4rLpzr5J6uDjFuYMVoAA 3vikEMKtxVqXHIqsfLyugJaXGcLSMEOZ934JyXSUwwwJRT7F6lKlJ0PLjRN/oFqheKnx AYTRpz+Crs+3wmFCWFM2Xe+hE/nFuzASt/O8R8Ff+dVhcZ+AEuk3s7L0mtz7//XRFXR/ gghA== X-Gm-Message-State: AElRT7EgWsiMNXzQx4X+3nJPNQI9aXCVqSkeuO1aFB1mASbxy0n5aJLe WpSYl0US2KU/ojc1NLd6R91yPAir X-Google-Smtp-Source: AIpwx48GEdlg30b0cTQQPasVc7uP0yh9u4eQnBojlseNHO1kWJBBzZnyCV1yNYW5f0n7D2qsoWUJaA== X-Received: by 10.80.177.81 with SMTP id l17mr20109757edd.65.1522838366933; Wed, 04 Apr 2018 03:39:26 -0700 (PDT) Received: from hollewijn.internal (84-245-13-9.dsl.cambrium.nl. [84.245.13.9]) by smtp.gmail.com with ESMTPSA id f21sm1514658edm.37.2018.04.04.03.39.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 03:39:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: kern.sched.quantum: Creepy, sadistic scheduler From: Alban Hertroys In-Reply-To: Date: Wed, 4 Apr 2018 12:39:24 +0200 Cc: freebsd-stable@FreeBSD.ORG Content-Transfer-Encoding: quoted-printable Message-Id: <9FDC510B-49D0-4722-B695-6CD38CA20D4A@gmail.com> References: To: Peter X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 10:39:28 -0000 > On 4 Apr 2018, at 2:52, Peter wrote: >=20 > Occasionally I noticed that the system would not quickly process the > tasks i need done, but instead prefer other, longrunning tasks. I > figured it must be related to the scheduler, and decided it hates me. If it hated you, it would behave much worse. > A closer look shows the behaviour as follows (single CPU): A single CPU? That's becoming rare! Is that a VM? Old hardware? = Something really specific? > Lets run an I/O-active task, e.g, postgres VACUUM that would And you're running a multi-process database server on it no less. That = is going to hurt, no matter how well the scheduler works. > continuousely read from big files (while doing compute as well [1]): > >pool alloc free read write read write > >cache - - - - - - > > ada1s4 7.08G 10.9G 1.58K 0 12.9M 0 >=20 > Now start an endless loop: > # while true; do :; done >=20 > And the effect is: > >pool alloc free read write read write > >cache - - - - - - > > ada1s4 7.08G 10.9G 9 0 76.8K 0 >=20 > The VACUUM gets almost stuck! This figures with WCPU in "top": >=20 > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND > >85583 root 99 0 7044K 1944K RUN 1:06 92.21% bash > >53005 pgsql 52 0 620M 91856K RUN 5:47 0.50% = postgres >=20 > Hacking on kern.sched.quantum makes it quite a bit better: > # sysctl kern.sched.quantum=3D1 > kern.sched.quantum: 94488 -> 7874 >=20 > >pool alloc free read write read write > >cache - - - - - - > > ada1s4 7.08G 10.9G 395 0 3.12M 0 >=20 > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND > >85583 root 94 0 7044K 1944K RUN 4:13 70.80% bash > >53005 pgsql 52 0 276M 91856K RUN 5:52 11.83% = postgres >=20 >=20 > Now, as usual, the "root-cause" questions arise: What exactly does > this "quantum"? Is this solution a workaround, i.e. actually something > else is wrong, and has it tradeoff in other situations? Or otherwise, > why is such a default value chosen, which appears to be ill-deceived? >=20 > The docs for the quantum parameter are a bit unsatisfying - they say > its the max num of ticks a process gets - and what happens when > they're exhausted? If by default the endless loop is actually allowed > to continue running for 94k ticks (or 94ms, more likely) = uninterrupted, > then that explains the perceived behaviour - buts thats certainly not > what a scheduler should do when other procs are ready to run. I can answer this from the operating systems course I followed recently. = This does not apply to FreeBSD specifically, it is general job = scheduling theory. I still need to read up on SCHED_ULE to see how the = details were implemented there. Or are you using the older SCHED_4BSD? Anyway... Jobs that are ready to run are collected on a ready queue. Since you = have a single CPU, there can only be a single job active on the CPU. = When that job is finished, the scheduler takes the next job in the ready = queue and assigns it to the CPU, etc. Now, that would cause a much worse situation in your example case. The = endless loop would keep running once it gets the CPU and would never = release it. No other process would ever get a turn again. You wouldn't = even be able to get into such a system in that state using remote ssh. That is why the scheduler has this "quantum", which limits the maximum = time the CPU will be assigned to a specific job. Once the quantum has = expired (with the job unfinished), the scheduler removes the job from = the CPU, puts it back on the ready queue and assigns the next job from = that queue to the CPU. That's why you seem to get better performance with a smaller value for = the quantum; the endless loop gets forcibly interrupted more often. This changing of the active job however, involves a context switch for = the CPU. Memory, registers, file handles, etc. that were required by the = previous job needs to be put aside and replaced by any such resources = related to the new job to be run. That uses up time and does nothing to = progress the jobs that are waiting for the CPU. Hence, you don't want = the quantum to be too small either, or you'll end up spending = significant time switching contexts. That gets worse when the job = involves system calls, which are handled by the kernel, which is also a = process that needs to be switched (and Meltdown made that worse, because = more rigorous clean-up is necessary to prevent peeks into sections of = memory that were owned by the kernel process previously). The "correct" value for the quantum depends on your type of workload. = PostgreSQL's auto-vacuum is a typical background process that will = probably (I didn't verify) request to be run at a lower priority, giving = other, more important, jobs more chance to get picked from the ready = queue (provided that the OS implements priority for the ready queue). That is probably why your endless loop gets much more CPU time than the = VACUUM process. It may be that FreeBSD's default value for the quantum = is not suitable for your workload. Finding the one best suited to you is = not particularly easy though - perhaps FreeBSD allows access to average = job times (below quantum) that can be used to calculate a reasonable = average from. That said, SCHED_ULE (the default scheduler for quite a while now) was = designed with multi-CPU configurations in mind and there are claims that = SCHED_4BSD works better for single-CPU configurations. You may give that = a try, if you're not already on SCHED_4BSD. A much better option in your case would be to put the database on a = multi-core machine. > [1] > A pure-I/O job without compute load, like "dd", does not show > this behaviour. Also, when other tasks are running, the unjust > behaviour is not so stongly pronounced. That is probably because dd has the decency to give the reins back to = the scheduler at regular intervals. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. From owner-freebsd-stable@freebsd.org Wed Apr 4 13:31:00 2018 Return-Path: Delivered-To: freebsd-stable@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 EC119F8EF65 for ; Wed, 4 Apr 2018 13:30:59 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout10.t-online.de (mailout10.t-online.de [194.25.134.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7377E7B5D5 for ; Wed, 4 Apr 2018 13:30:59 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd03.aul.t-online.de (fwd03.aul.t-online.de [172.20.27.148]) by mailout10.t-online.de (Postfix) with SMTP id CDF9941E40D0; Wed, 4 Apr 2018 15:30:51 +0200 (CEST) Received: from Stefans-MBP-7.fritz.box (V8cXzaZ6Yh6xiupXF5oX2Z0H-3khQ-lb5lHGM7a-5pUDtLRT+j0sJt57QXaFHmSZZy@[84.154.99.226]) by fwd03.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1f3iUx-0qESyu0; Wed, 4 Apr 2018 15:30:47 +0200 Subject: Try setting kern.sched.preempt_thresh != 0 (was: Re: kern.sched.quantum: Creepy, sadistic scheduler) To: Alban Hertroys , Peter Cc: freebsd-stable@FreeBSD.ORG References: <9FDC510B-49D0-4722-B695-6CD38CA20D4A@gmail.com> From: Stefan Esser Openpgp: preference=signencrypt Autocrypt: addr=se@freebsd.org; prefer-encrypt=mutual; keydata= xsBNBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAHNLlN0ZWZhbiBFw59lciAoVC1PbmxpbmUpIDxzdC5lc3NlckB0LW9ubGluZS5kZT7CwH8E EwEIACkFAlhtTvQCGwMFCQWjmoAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRBH67Xv Wv31RAn0B/9skuajrZxjtCiaOFeJw9l8qEOSNF6PKMN2i/wosqNK57yRQ9AS18x4+mJKXQtc mwyejjQTO9wasBcniKMYyUiie3p7iGuFR4kSqi4xG7dXKjMkYvArWH5DxeWBrVf94yPDexEV FnEG9t1sIXjL17iFR8ng5Kkya5yGWWmikmPdtZChj9OUq4NKHKR7/HGM2dxP3I7BheOwY9PF 4mhqVN2Hu1ZpbzzJo68N8GGBmpQNmahnTsLQ97lsirbnPWyMviWcbzfBCocI9IlepwTCqzlN FMctBpLYjpgBwHZVGXKucU+eQ/FAm+6NWatcs7fpGr7dN99S8gVxnCFX1Lzp/T1YzsBNBFVx iRIBCACxI/aglzGVbnI6XHd0MTP05VK/fJub4hHdc+LQpz1MkVnCAhFbY9oecTB/togdKtfi loavjbFrb0nJhJnx57K+3SdSuu+znaQ4SlWiZOtXnkbpRWNUeMm+gtTDMSvloGAfr76RtFHs kdDOLgXsHD70bKuMhlBxUCrSwGzHaD00q8iQPhJZ5itb3WPqz3B4IjiDAWTO2obD1wtAvSuH uUj/XJRsiKDKW3x13cfavkad81bZW4cpNwUv8XHLv/vaZPSAly+hkY7NrDZydMMXVNQ7AJQu fWuTJ0q7sImRcEZ5EIa98esJPey4O7C0vY405wjeyxpVZkpqThDMurqtQFn1ABEBAAHCwGUE GAEKAA8FAlVxiRICGwwFCQWjmoAACgkQR+u171r99UQEHAf/ZxNbMxwX1v/hXc2ytE6yCAil piZzOffT1VtS3ET66iQRe5VVKL1RXHoIkDRXP7ihm3WF7ZKy9yA9BafMmFxsbXR3+2f+oND6 nRFqQHpiVB/QsVFiRssXeJ2f0WuPYqhpJMFpKTTW/wUWhsDbytFAKXLLfesKdUlpcrwpPnJo KqtVbWAtQ2/o3y+icYOUYzUig+CHl/0pEPr7cUhdDWqZfVdRGVIk6oy00zNYYUmlkkVoU7MB V5D7ZwcBPtjs254P3ecG42szSiEo2cvY9vnMTCIL37tX0M5fE/rHub/uKfG2+JdYSlPJUlva RS1+ODuLoy1pzRd907hl8a7eaVLQWA== Message-ID: Date: Wed, 4 Apr 2018 15:30:46 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <9FDC510B-49D0-4722-B695-6CD38CA20D4A@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ID: V8cXzaZ6Yh6xiupXF5oX2Z0H-3khQ-lb5lHGM7a-5pUDtLRT+j0sJt57QXaFHmSZZy X-TOI-MSGID: 246fb8cb-6076-46e7-bba8-8f9fed7ec667 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 13:31:00 -0000 Am 04.04.18 um 12:39 schrieb Alban Hertroys: > >> On 4 Apr 2018, at 2:52, Peter wrote: >> >> Occasionally I noticed that the system would not quickly process the >> tasks i need done, but instead prefer other, longrunning tasks. I >> figured it must be related to the scheduler, and decided it hates me. > > If it hated you, it would behave much worse. > >> A closer look shows the behaviour as follows (single CPU): > > A single CPU? That's becoming rare! Is that a VM? Old hardware? Something really specific? > >> Lets run an I/O-active task, e.g, postgres VACUUM that would > > And you're running a multi-process database server on it no less. That is going to hurt, no matter how well the scheduler works. > >> continuousely read from big files (while doing compute as well [1]): >>> pool alloc free read write read write >>> cache - - - - - - >>> ada1s4 7.08G 10.9G 1.58K 0 12.9M 0 >> >> Now start an endless loop: >> # while true; do :; done >> >> And the effect is: >>> pool alloc free read write read write >>> cache - - - - - - >>> ada1s4 7.08G 10.9G 9 0 76.8K 0 >> >> The VACUUM gets almost stuck! This figures with WCPU in "top": >> >>> PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND >>> 85583 root 99 0 7044K 1944K RUN 1:06 92.21% bash >>> 53005 pgsql 52 0 620M 91856K RUN 5:47 0.50% postgres >> >> Hacking on kern.sched.quantum makes it quite a bit better: >> # sysctl kern.sched.quantum=1 >> kern.sched.quantum: 94488 -> 7874 >> >>> pool alloc free read write read write >>> cache - - - - - - >>> ada1s4 7.08G 10.9G 395 0 3.12M 0 >> >>> PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND >>> 85583 root 94 0 7044K 1944K RUN 4:13 70.80% bash >>> 53005 pgsql 52 0 276M 91856K RUN 5:52 11.83% postgres >> >> >> Now, as usual, the "root-cause" questions arise: What exactly does >> this "quantum"? Is this solution a workaround, i.e. actually something >> else is wrong, and has it tradeoff in other situations? Or otherwise, >> why is such a default value chosen, which appears to be ill-deceived? >> >> The docs for the quantum parameter are a bit unsatisfying - they say >> its the max num of ticks a process gets - and what happens when >> they're exhausted? If by default the endless loop is actually allowed >> to continue running for 94k ticks (or 94ms, more likely) uninterrupted, >> then that explains the perceived behaviour - buts thats certainly not >> what a scheduler should do when other procs are ready to run. > > I can answer this from the operating systems course I followed recently. This does not apply to FreeBSD specifically, it is general job scheduling theory. I still need to read up on SCHED_ULE to see how the details were implemented there. Or are you using the older SCHED_4BSD? > Anyway... > > Jobs that are ready to run are collected on a ready queue. Since you have a single CPU, there can only be a single job active on the CPU. When that job is finished, the scheduler takes the next job in the ready queue and assigns it to the CPU, etc. I'm guessing that the problem is caused by kern.sched.preempt_thresh=0, which prevents preemption of low priority processes by interactive or I/O bound processes. For a quick test try: # sysctl kern.sched.preempt_thresh=1 to see whether it makes a difference. The value 1 is unreasonably low, but it has the most visible effect in that any higher priority process can steal the CPU from any lower priority one (high priority corresponds to low PRI values as displayed by ps -l or top). Reasonable values might be in the range of 80 to 224 depending on the system usage scenario (that's what I found to have been suggested in the mail-lists). Higher values result in less preemption. Regards, STefan From owner-freebsd-stable@freebsd.org Wed Apr 4 13:40:11 2018 Return-Path: Delivered-To: freebsd-stable@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 4D11AF8F9DA for ; Wed, 4 Apr 2018 13:40:11 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "m5p.com", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9BCBA7BC1F for ; Wed, 4 Apr 2018 13:40:10 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPv6:2001:470:1f07:15ff::1f] (haymarket.m5p.com [IPv6:2001:470:1f07:15ff::1f]) (authenticated bits=0) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTPSA id w34DX4Od058196 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 4 Apr 2018 09:33:13 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Subject: Re: kern.sched.quantum: Creepy, sadistic scheduler To: freebsd-stable@freebsd.org References: <9FDC510B-49D0-4722-B695-6CD38CA20D4A@gmail.com> From: George Mitchell Openpgp: preference=signencrypt Autocrypt: addr=george+freebsd@m5p.com; prefer-encrypt=mutual; keydata= xsFNBFgnLnwBEADAJDiBKQX77LFRz9wZW8mz3KvaQol2nIremcws0F1mz/zgFlk6uhQVtwnL wb4XL5LdFwcNE1+QZzPLcbYWoWQlz0lBw1bMuKAgr0S6V2e0+I0DqhKeslVFctcTwtvT6pnK VLZXO/7ZGAaLzG4K5vSPzgoevU+YI/pxNsVCH2UO/c3jQW63uEt25mIZbCF1Pu4jgp4RhIgF ujn877r/j6OwBwjzRUu3E6ADp+U825d+5YCuQMEH0wIPnn9GTpXvfdKdbwOIl2akqXqs4cnk iATWfK3r6D4mvDEj1OPHlTvJYcfic7aOIiAwmx1C1v78GjXOdOOA0SGffNix3C2/8oZUO1+V Aet4MKpUKkduWSvULhIkHNZ5Nu8SIJOqge8pmtHxuNXAMfMrAjMdjPwwBFLsYg3Xa2E2oJwg ehTauwd/EDJFcVCyDCyCAYOi/BH/+XQyxzgDlY9N9qj9tHqhVPI6XK7t8UVffGiZUq4rHp5J RdOToqiTNC6eCJBczhMIW+DuFvWU9e6W708T1dz0Accn6Lrgk4eRIn3GFPBG+TxnpjAqHsbW 607dcnD3YKAqY4e+khczL4EObhe7dC1v2fmZiAC6Ds3WHR11IfqoUgCkIwJ590Ej+ElygJFF XxI82wtEz9hkeLLvItpyEJNVjppViRW+Dgl/U7ypHB3qDgYjgwARAQABzSBHZW9yZ2UgTWl0 Y2hlbGwgPGdlb3JnZUBtNXAuY29tPsLBlwQTAQgAQQIbIwUJCWYBgAULCQgHAgYVCAkKCwIE FgIDAQIeAQIXgBYhBDXTOGR5LbCVuZCmV8EREt5vqeH5BQJYWXFRAhkBAAoJEMEREt5vqeH5 SRsQAIb/crcxXyAyeokAuTjN+YXkEFdVv/JrOgNXKdCukXt/UGd3nZTcAzpllytDIvIlPTNI 2/nZ5sm6ymeyVwmvkrM/r3sRUib5ftakJpbv0wn2j+eCGAca8IA2frBUg9bEXKcHRJRQCztG cpousHzOziTCRQ/1NfPcIFBNbQMPUVoQ96cJPvM/XfFGOISKKsSI78skHm6Oazh1hLCQTKvy hNNgVpNP/PHCHMbla1+SNgyn35CUelTh153lnkOhw1XyX6IxY4o5Bhcf3YrxAVcoeHq3FEH0 T3ygAdI14VrZGXXitBAMI78QLB0FiWMoPQ3Oddnoh6tlT4djnsc9IW0Tzk6ozvQL7sKdYgO8 ZlIpkBqQQfpSHzwPu9EkOFggPWB9WtP3IajQ0lt1LovqMug4C8APRC2/1cvi+GUIRwjVsop0 ukhlLTTJd3/S4Muh3s87M4Rdek1xpOiMKjYOVaxmhQQ91oz971zJuJJWpX7uUQiXx9oEwCDW TvI5yEuqYLsMUwx3d2iFTr+HbtlBJmF+Vguyrn/a3vFK8P/TH9fMvNeTdln9SuOOa1SAMMcy czOpBYg9RpzNLshUJVrhKzugT59Rl2wsNQsQCUkzgF3f8cZHJyl+8x6t0nuM9LTkMv13YIXS Mde3UOD2EaBhmeIqvC/adQHxpNudvxM1viFJDnTnzsFNBFgnLnwBEAC7kzsZqjBRPonnr/63 C98FSa3LikvqQWygmPSCC9DsFX/fB0CSXIHTrHQ4a7lXdfZyTZcGdxXN+MC8O8thjvVq6WYm CpyOJ/bq4SxOa9cnQSJ5SP9VCmVoDN/3T4ybXFzLAt756kfQ5jsVuP0m6iQ4z918zhZXk+Mo qdwGjYTxsBD02a7m1aeYafyaI2mZ+vdEy0cDhV4PDXI6ThLNAavTPji6ZrBdH5a4LMg30u8v kkNe0eCKvU+0cWb2VQIeddMhhiGSBE2Dv+A4eNe1VZvoGpLDlYdnoHraVFL2GHNFGymj/uRf 1hja5kW9Rekisqby5SpGABwrFFEs7ABpfYG0IRBKbjjG1Cqdfe/R6ETJFvvNOOpCKPAWeqYf Isxv4OHWTmhKihhIanYWCAe1MDLRRbj7UrOTZeia2WJ4v58xbU5rVQoHI/Tzaq86rXzRWITc 5w+kresMad0zpvQ900BdHc8ATNY2aW/Fr5it5OqMvIW6Y4gc8Z95MkQPVc8vj3WzfxuWtZNK 6Wbv4r6Qbiwg1RpY1JoEIoF4OsZJOVMQaB6ezD7xvaa2eY6nRGtq9SoJxo2qvlSbLlKq8NdH VYHhtTbpQ1NfrEJfv5sLX5W5IpoYww48bFYH67+7r1f/W3voBptSgE7qnYAm6Em9bEAKOQEX 8BXwoa54fn03z6TyhwARAQABwsFkBBgBCAAPBQJYJy58AhsMBQkJZgGAAAoJEMEREt5vqeH5 6PcP+JvrMM7ZM8UlnbrY4Er9psPj3ayllRhQFA9h6GNUKYuSzSxOrPaT96s8KUGMCr4jrn1S WFmeeNLLOgSJmQRicMh6LmnKq6WY6UaOfn7Y9O62NUjXfEI3Bw4ID36YCdQ+CJd14r0YOf4M 5F50bvHV3lbzD9TXZPxecHKC2ZUMBbT37tsckWCLL3lzKMsqQLwBUmgBl1NIUc7gyXxiNyxb 6SPVF1NguDDM438mcg9jSRAyjgAk6POUEM8YIXkw0Gg6HF1tNMJJ1xTMBCLYl6fHTtsxJpf9 yo+Hnw346hqYzXn4ytHJ49Ngcre8uhqM1l8iMpa17tEjfalkc1FWR9/qvoowOKtxpvblsy3a YzeEFgIomhLzISz6IafQ3S7Mt5AFlqwN/qQHx0k2V66GzDG0ngZBPROP1sXSpdJzO0zbJQFn MZE3f+y8vXMcE/MBXR7kAdYYApiEMQzVxy9TdQDU3lGLptcPZ1IOntTNFFrvp5NwsKi+6C9i mXtd5kJ1PwhcJYW3/ov/490l60C5SFUL/RZ/NOW8SHFaPcqlGcqIlexFKbzrMQwmYXo95jWB eZ0Qn+raxCUFZNGiwtusyQGBMcpHVJUanOCNd1z4ZbfmhUjDJKC/7YWDunvaDRSukGiRCl6J s8caqXHiVZjx+s76iWzm6AHRP5jg9D6EtTOrGiE= Message-ID: <8cfdb8a3-86a0-17ba-1e41-ff1912a30ee9@m5p.com> Date: Wed, 4 Apr 2018 09:32:58 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <9FDC510B-49D0-4722-B695-6CD38CA20D4A@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WUn6KnCTH8ZEmq2EMEP6deMcF0ejBOuWh" X-Spam-Status: No, score=0.2 required=10.0 tests=HELO_MISC_IP, RP_MATCHES_RCVD autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mattapan.m5p.com X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mailhost.m5p.com [IPv6:2001:470:1f07:15ff::f7]); Wed, 04 Apr 2018 09:33:19 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 13:40:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WUn6KnCTH8ZEmq2EMEP6deMcF0ejBOuWh Content-Type: multipart/mixed; boundary="JRV7paM4PpDZXsQ9u1yr1TNhOr6SdaaPA"; protected-headers="v1" From: George Mitchell To: freebsd-stable@freebsd.org Message-ID: <8cfdb8a3-86a0-17ba-1e41-ff1912a30ee9@m5p.com> Subject: Re: kern.sched.quantum: Creepy, sadistic scheduler References: <9FDC510B-49D0-4722-B695-6CD38CA20D4A@gmail.com> In-Reply-To: <9FDC510B-49D0-4722-B695-6CD38CA20D4A@gmail.com> --JRV7paM4PpDZXsQ9u1yr1TNhOr6SdaaPA Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/04/18 06:39, Alban Hertroys wrote: > [...] > That said, SCHED_ULE (the default scheduler for quite a while now) was = designed with multi-CPU configurations in mind and there are claims that = SCHED_4BSD works better for single-CPU configurations. You may give that = a try, if you're not already on SCHED_4BSD. > [...] A small, disgruntled community of FreeBSD users who have never seen proof that SCHED_ULE is better than SCHED_4BSD in any environment continue to regularly recompile with SCHED_4BSD. I dread the day when that becomes impossible, but at least it isn't here yet. -- George --JRV7paM4PpDZXsQ9u1yr1TNhOr6SdaaPA-- --WUn6KnCTH8ZEmq2EMEP6deMcF0ejBOuWh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAlrE1AsACgkQwRES3m+p 4fmfdQ//RUqnwY4RfdptoaKqcPK5UO4P2MP9CedcO+Q3KGtqVzLlNFC3jTnGQuCH HKApDDoAgtIJj3pfJdszwNK5dA16k0j0Cu+LPkaB00OS0Z2yUzeAxW2oYc/WYsij /sPGEf6A4yRyaX/lRhKK+RJA/fe5ilnKMohAohyclQd2eou18A89FTTwT+EdeK25 LKhVJOXsiXrMDmQPAs6AwnNJKNzKPzr06TONnUZJDictcaDCioKtONGzN4J0Rsw+ t2PDcVeqQ+SIcfPxx8UsU3PAEhNX8e0IiUIpngtT7R8TKOmmC3NLmqBm+zW7Bjcc okhZotAgroy51u261O6HiuJ3sPooETMB2rIKswQrAZx2C2f9fRcgH28GDGiBZcRq UWHqUI23+/YR9vMz25CzhduHohdjD68PRJuxESOLksATE03Txkfn4BG8W0xpE/ft 8FcEnAmdidgQ1UKg2ylw7sbYJ+nLpQdzesL/1di7TS1ecbDqES3MwbxuMTlAHR3o XoODx8doWt2t9rzx6gAW46ZiI1WHmJ7T7PxzRluRcrOWg4m8qMaJzCxgpQpvUid0 BF2r+7alEzrgBJ1WwEKLZx9LzqfkftY3g+IxXfcedMKsOJhKkJ4peAyAk5lZfgXJ yWH22fQW4O6KHjUaeStV5/VKH6A31UO7BnAC1YO7IC2aNEwEguU= =7EWO -----END PGP SIGNATURE----- --WUn6KnCTH8ZEmq2EMEP6deMcF0ejBOuWh-- From owner-freebsd-stable@freebsd.org Wed Apr 4 14:30:21 2018 Return-Path: Delivered-To: freebsd-stable@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 4F463F930C1 for ; Wed, 4 Apr 2018 14:30:21 +0000 (UTC) (envelope-from veronica.baker@showezdeligates.com) Received: from homiemail-a118.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E237C7E572 for ; Wed, 4 Apr 2018 14:30:20 +0000 (UTC) (envelope-from veronica.baker@showezdeligates.com) Received: from homiemail-a118.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a118.g.dreamhost.com (Postfix) with ESMTP id D1BCD6000FF6D for ; Wed, 4 Apr 2018 07:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=showezdeligates.com; h= from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type; s=showezdeligates.com; bh=uo4Hy/tfoi jnOhq2PbMW5okAivM=; b=A+2a8t61FT6y7eWPJ5NjbfSFUE1svC0iJ6ez08QmNi 4sIqzAU1lJgrmCiBURyUATk+tuleETkqV/lVmvzrkkQR9s7kyJFvvospcI/b+0E8 Tug0NpG3exwVwQt0mF/r0kLmIcZeKTSpVhl2WdBtBd1SZdPh7hCbmYNU08PSS8gU M= Received: from NESS14PC (unknown [106.51.21.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: veronica.baker@showezdeligates.com) by homiemail-a118.g.dreamhost.com (Postfix) with ESMTPSA id 736CD6000FF6A for ; Wed, 4 Apr 2018 07:30:11 -0700 (PDT) From: "Veronica Baker" To: References: In-Reply-To: Subject: RE: Delegates Email list of Atlanta Apartment Association 2018 Date: Wed, 4 Apr 2018 10:29:58 -0400 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdPF05vJbzoiiCPDSMWN44RF3flbeABCPxQgACig98AAAAAV8AAAAAHgAAAABlAAAALsEAAAABQAAAAABgAAAAAHMAAAAAdgAAAACfAAAAINkAAAAi9gAAAAFKAAAAAIUAEoiwXA Content-Language: en-in Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 14:30:21 -0000 Hi, I hope you're doing well. I was wondering if you had a chance to review my previous email that I sent to you. Kindly let me know your interest so that i can get back to you with counts and pricing available. Best Regards, Veronica Baker From: Veronica Baker [mailto:veronica.baker@showezdeligates.com] Sent: 29 March 2018 12:59 To: 'freebsd-stable@freebsd.org' Subject: Delegates Email list of Atlanta Apartment Association 2018 Hi, Would you be interested in Attendees Email List Of Atlanta Apartment Association 2018.? Attendees: . Decision Makers . Apartment owners . Managers . Suppliers, and Professionals List includes: E-mails, contact number and other fields on an excel sheet. Would you like to see counts and pricing details available.? Looking forward for your email. Regards, Veronica Baker| B.D.Exe If you do not wish to receive future emails from us, please reply as "Exclude Me" From owner-freebsd-stable@freebsd.org Wed Apr 4 14:35:05 2018 Return-Path: Delivered-To: freebsd-stable@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 65BCFF93612 for ; Wed, 4 Apr 2018 14:35:05 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B27267EB9E for ; Wed, 4 Apr 2018 14:35:04 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.sub.de (8.15.2/8.15.2) with ESMTPS id w34EYwtK099971 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 4 Apr 2018 16:34:58 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.15.2/8.15.2/Submit) with UUCP id w34EYwsv099970 for freebsd-stable@FreeBSD.ORG; Wed, 4 Apr 2018 16:34:58 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id w34EFBl3006698 for ; Wed, 4 Apr 2018 16:15:11 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id w34EE3m5006517 for ; Wed, 4 Apr 2018 16:14:03 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id w34EE3o3006516 for freebsd-stable@FreeBSD.ORG; Wed, 4 Apr 2018 16:14:03 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: Re: Try setting kern.sched.preempt_thresh != 0 Date: Wed, 4 Apr 2018 16:08:41 +0200 Organization: even some more stinky socks Message-ID: References: <9FDC510B-49D0-4722-B695-6CD38CA20D4A@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 4 Apr 2018 14:09:12 -0000 (UTC) Injection-Info: oper.dinoex.de; logging-data="5696"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48 In-Reply-To: Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.sub.de [194.45.71.2]); Wed, 04 Apr 2018 16:34:59 +0200 (CEST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 14:35:05 -0000 Stefan Esser wrote: > > I'm guessing that the problem is caused by kern.sched.preempt_thresh=0, which > prevents preemption of low priority processes by interactive or I/O bound > processes. > > For a quick test try: > > # sysctl kern.sched.preempt_thresh=1 Hi Stefan, thank You, thats an interesting knob! Only it is actually the other way round: it is not set to 0. My settings (as default) are: kern.sched.steal_thresh: 2 kern.sched.steal_idle: 1 kern.sched.balance_interval: 127 kern.sched.balance: 1 kern.sched.affinity: 1 kern.sched.idlespinthresh: 157 kern.sched.idlespins: 10000 kern.sched.static_boost: 152 kern.sched.preempt_thresh: 80 kern.sched.interact: 30 kern.sched.slice: 12 kern.sched.quantum: 94488 kern.sched.name: ULE kern.sched.preemption: 1 kern.sched.cpusetsize: 4 But then, if I change kern.sched.preempt_thresh to 1 *OR* 0, things behave properly! Precisely, changing from 8 down to 7 changes things completely: >pool alloc free read write read write >cache - - - - - - > ada1s4 7.08G 10.9G 927 0 7.32M 0 > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND > 1900 pgsql 82 0 618M 17532K RUN 0:53 34.90% postgres > 1911 admin 81 0 7044K 2824K RUN 6:07 28.34% bash (Notice the PRI values which also look differnt now.) rgds, P. From owner-freebsd-stable@freebsd.org Wed Apr 4 14:35:04 2018 Return-Path: Delivered-To: freebsd-stable@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 95FA4F9360A for ; Wed, 4 Apr 2018 14:35:04 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EFC7B7EB9C for ; Wed, 4 Apr 2018 14:35:03 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.sub.de (8.15.2/8.15.2) with ESMTPS id w34EYxh6099976 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 4 Apr 2018 16:35:00 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.15.2/8.15.2/Submit) with UUCP id w34EYxYF099975 for freebsd-stable@FreeBSD.ORG; Wed, 4 Apr 2018 16:34:59 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id w34EOBbt007984 for ; Wed, 4 Apr 2018 16:24:11 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id w34EO2VR007902 for ; Wed, 4 Apr 2018 16:24:02 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id w34EO2LH007901 for freebsd-stable@FreeBSD.ORG; Wed, 4 Apr 2018 16:24:02 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: Re: kern.sched.quantum: Creepy, sadistic scheduler Date: Wed, 4 Apr 2018 16:16:25 +0200 Organization: even some more stinky socks Message-ID: References: <9FDC510B-49D0-4722-B695-6CD38CA20D4A@gmail.com> <8cfdb8a3-86a0-17ba-1e41-ff1912a30ee9@m5p.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 4 Apr 2018 14:16:26 -0000 (UTC) Injection-Info: oper.dinoex.de; logging-data="6803"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48 In-Reply-To: <8cfdb8a3-86a0-17ba-1e41-ff1912a30ee9@m5p.com> Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.sub.de [194.45.71.2]); Wed, 04 Apr 2018 16:35:01 +0200 (CEST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 14:35:04 -0000 George Mitchell wrote: > On 04/04/18 06:39, Alban Hertroys wrote: >> [...] >> That said, SCHED_ULE (the default scheduler for quite a while now) was designed with multi-CPU configurations in mind and there are claims that SCHED_4BSD works better for single-CPU configurations. You may give that a try, if you're not already on SCHED_4BSD. >> [...] > > A small, disgruntled community of FreeBSD users who have never seen > proof that SCHED_ULE is better than SCHED_4BSD in any environment > continue to regularly recompile with SCHED_4BSD. I dread the day when > that becomes impossible, but at least it isn't here yet. -- George > Yes *laugh*, I found a very lengthy and mind-boggling discussion from back in 2011. And I found that You made this statement somewhere there: // With nCPU compute-bound processes running, with SCHED_ULE, any other // process that is interactive (which to me means frequently waiting for // I/O) gets ABYSMAL performance -- over an order of magnitude worse // than it gets with SCHED_4BSD under the same conditions. -- https://lists.freebsd.org/pipermail/freebsd-stable/2011-December/064984.html And this describes quite exactly what I perceive. Now, I would like to ask: what has been done about this issue? P. From owner-freebsd-stable@freebsd.org Wed Apr 4 15:13:35 2018 Return-Path: Delivered-To: freebsd-stable@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 97D2FF95FCF for ; Wed, 4 Apr 2018 15:13:35 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DC5D78093B for ; Wed, 4 Apr 2018 15:13:34 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.sub.de (8.15.2/8.15.2) with ESMTPS id w34FD4mB013240 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 4 Apr 2018 17:13:04 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.15.2/8.15.2/Submit) with UUCP id w34FD4F5013238 for freebsd-stable@FreeBSD.ORG; Wed, 4 Apr 2018 17:13:04 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id w34EjCmQ010771 for ; Wed, 4 Apr 2018 16:45:12 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id w34Ei2wk010545 for ; Wed, 4 Apr 2018 16:44:02 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id w34Ei2gf010543 for freebsd-stable@FreeBSD.ORG; Wed, 4 Apr 2018 16:44:02 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: Re: kern.sched.quantum: Creepy, sadistic scheduler Date: Wed, 4 Apr 2018 16:34:44 +0200 Organization: even some more stinky socks Message-ID: References: <9FDC510B-49D0-4722-B695-6CD38CA20D4A@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 4 Apr 2018 14:34:45 -0000 (UTC) Injection-Info: oper.dinoex.de; logging-data="9242"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48 In-Reply-To: <9FDC510B-49D0-4722-B695-6CD38CA20D4A@gmail.com> Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.sub.de [194.45.71.2]); Wed, 04 Apr 2018 17:13:05 +0200 (CEST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 15:13:35 -0000 Hi Alban! Alban Hertroys wrote: >> Occasionally I noticed that the system would not quickly process the >> tasks i need done, but instead prefer other, longrunning tasks. I >> figured it must be related to the scheduler, and decided it hates me. > > If it hated you, it would behave much worse. Thats encouraging :) But I would say, running a job 100 times slower than expected is quite an amount of hate for my taste. >> A closer look shows the behaviour as follows (single CPU): > > A single CPU? That's becoming rare! Is that a VM? Old hardware? Something really specific? I don't plug in another CPU because there is no need to. Yes, its old hardware: CPU: Intel Pentium III (945.02-MHz 686-class CPU) ACPI APIC Table: If I had bought new hardware, this one would now rot in Africa, and I would have new hardware idling along that is spectre/meltdown affected nevertheless. >> Lets run an I/O-active task, e.g, postgres VACUUM that would > > And you're running a multi-process database server on it no less. That > is going to hurt, I'm running a lot more than only that on it. But it's all private use, idling most of the time. > no matter how well the scheduler works. Maybe. But this post is not about my personal expectations on over-all performance - it is about a specific behaviour that is not how a scheduler is expected to behave - no matter if we're on a PDP-11 or on a KabyLake. >> Now, as usual, the "root-cause" questions arise: What exactly does >> this "quantum"? Is this solution a workaround, i.e. actually something >> else is wrong, and has it tradeoff in other situations? Or otherwise, >> why is such a default value chosen, which appears to be ill-deceived? >> >> The docs for the quantum parameter are a bit unsatisfying - they say >> its the max num of ticks a process gets - and what happens when >> they're exhausted? If by default the endless loop is actually allowed >> to continue running for 94k ticks (or 94ms, more likely) uninterrupted, >> then that explains the perceived behaviour - buts thats certainly not >> what a scheduler should do when other procs are ready to run. > > I can answer this from the operating systems course I followed recently. This does not apply to FreeBSD specifically, it is general job scheduling theory. I still need to read up on SCHED_ULE to see how the details were implemented there. Or are you using the older SCHED_4BSD? I'm using the default scheduler, which is ULE. I would not go non-default without reason. (But it seems, a reason is just appering now.) > Now, that would cause a much worse situation in your example case. The endless loop would keep running once it gets the CPU and would never release it. No other process would ever get a turn again. You wouldn't even be able to get into such a system in that state using remote ssh. > > That is why the scheduler has this "quantum", which limits the maximum time the CPU will be assigned to a specific job. Once the quantum has expired (with the job unfinished), the scheduler removes the job from the CPU, puts it back on the ready queue and assigns the next job from that queue to the CPU. > That's why you seem to get better performance with a smaller value for the quantum; the endless loop gets forcibly interrupted more often. Good description. Only my (old-fashioned) understanding was that this is the purpose of the HZ value: to give control back to the kernel, so that a new decision can be made. So, I would not have been surpized to see 200 I/Os for postgres (kern.hz=200), but what I see is 9 I/Os (which indeed figures to a "quantum" of 94ms). But then, we were able to do all this nicely on single-CPU machines for almost four decades. It does not make sense to me if now we state that we cannot do it anymore because single-CPU is uncommon today. (Yes indeed, we also cannot fly to the moon anymore, because today nobody seems to recall how that stuff was built. *headbangwall*) > This changing of the active job however, involves a context switch for the CPU. Memory, registers, file handles, etc. that were required by the previous job needs to be put aside and replaced by any such resources related to the new job to be run. That uses up time and does nothing to progress the jobs that are waiting for the CPU. Hence, you don't want the quantum to be too small either, or you'll end up spending significant time switching contexts. Yepp. My understanding was that I can influence this behaviour via the HZ value, so to tradeoff responsiveness against performance. Obviousely that was wrong. From Your writing, it seems the "quantum" is indeed the correct place to tune this. (But I will still have to ponder a while about the knob mentioned by Stefan, concerning preemption, which seems to magically resolve the issue.) > That said, SCHED_ULE (the default scheduler for quite a while now) was designed with multi-CPU configurations in mind and there are claims that SCHED_4BSD works better for single-CPU configurations. You may give that a try, if you're not already on SCHED_4BSD. I'll try this at next code update. > A much better option in your case would be to put the database on a multi-core machine. I could plug in the second CPU, but it would mostly just heat the room. So, a modern low-energy CPU would do better - but then, try to get a modern CPU (+board!) that supports ECC-ram, and you'll end in the high-end department. This old one does, so it's just perfect for 24/365. Nevertheless, this is a software issue, and fixing it via new hardware should be only the last resort. >> [1] >> A pure-I/O job without compute load, like "dd", does not show >> this behaviour. Also, when other tasks are running, the unjust >> behaviour is not so stongly pronounced. > > That is probably because dd has the decency to give the reins back to the scheduler at regular intervals. No, rather the other way round: running dd against the piglet (aka endless loop), both run full-speed. Running postgres VACUUM against the piglet, postgres starves. My (rather vague) explanation: when an I/O for dd comes back, dd immediately requests the next one. When an I/O for postgres comes back, postgres needs to compute their transaction ID stuff, competes against the piglet for CPU, and looses. P. From owner-freebsd-stable@freebsd.org Wed Apr 4 17:01:56 2018 Return-Path: Delivered-To: freebsd-stable@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 C7082F9D183 for ; Wed, 4 Apr 2018 17:01:56 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "m5p.com", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 551D6860F1 for ; Wed, 4 Apr 2018 17:01:56 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPv6:2001:470:1f07:15ff::1f] (haymarket.m5p.com [IPv6:2001:470:1f07:15ff::1f]) (authenticated bits=0) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTPSA id w34H0GJH059718 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 4 Apr 2018 13:01:42 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Subject: Re: kern.sched.quantum: Creepy, sadistic scheduler To: freebsd-stable@freebsd.org References: <9FDC510B-49D0-4722-B695-6CD38CA20D4A@gmail.com> From: George Mitchell Openpgp: preference=signencrypt Autocrypt: addr=george+freebsd@m5p.com; prefer-encrypt=mutual; keydata= xsFNBFgnLnwBEADAJDiBKQX77LFRz9wZW8mz3KvaQol2nIremcws0F1mz/zgFlk6uhQVtwnL wb4XL5LdFwcNE1+QZzPLcbYWoWQlz0lBw1bMuKAgr0S6V2e0+I0DqhKeslVFctcTwtvT6pnK VLZXO/7ZGAaLzG4K5vSPzgoevU+YI/pxNsVCH2UO/c3jQW63uEt25mIZbCF1Pu4jgp4RhIgF ujn877r/j6OwBwjzRUu3E6ADp+U825d+5YCuQMEH0wIPnn9GTpXvfdKdbwOIl2akqXqs4cnk iATWfK3r6D4mvDEj1OPHlTvJYcfic7aOIiAwmx1C1v78GjXOdOOA0SGffNix3C2/8oZUO1+V Aet4MKpUKkduWSvULhIkHNZ5Nu8SIJOqge8pmtHxuNXAMfMrAjMdjPwwBFLsYg3Xa2E2oJwg ehTauwd/EDJFcVCyDCyCAYOi/BH/+XQyxzgDlY9N9qj9tHqhVPI6XK7t8UVffGiZUq4rHp5J RdOToqiTNC6eCJBczhMIW+DuFvWU9e6W708T1dz0Accn6Lrgk4eRIn3GFPBG+TxnpjAqHsbW 607dcnD3YKAqY4e+khczL4EObhe7dC1v2fmZiAC6Ds3WHR11IfqoUgCkIwJ590Ej+ElygJFF XxI82wtEz9hkeLLvItpyEJNVjppViRW+Dgl/U7ypHB3qDgYjgwARAQABzSBHZW9yZ2UgTWl0 Y2hlbGwgPGdlb3JnZUBtNXAuY29tPsLBlwQTAQgAQQIbIwUJCWYBgAULCQgHAgYVCAkKCwIE FgIDAQIeAQIXgBYhBDXTOGR5LbCVuZCmV8EREt5vqeH5BQJYWXFRAhkBAAoJEMEREt5vqeH5 SRsQAIb/crcxXyAyeokAuTjN+YXkEFdVv/JrOgNXKdCukXt/UGd3nZTcAzpllytDIvIlPTNI 2/nZ5sm6ymeyVwmvkrM/r3sRUib5ftakJpbv0wn2j+eCGAca8IA2frBUg9bEXKcHRJRQCztG cpousHzOziTCRQ/1NfPcIFBNbQMPUVoQ96cJPvM/XfFGOISKKsSI78skHm6Oazh1hLCQTKvy hNNgVpNP/PHCHMbla1+SNgyn35CUelTh153lnkOhw1XyX6IxY4o5Bhcf3YrxAVcoeHq3FEH0 T3ygAdI14VrZGXXitBAMI78QLB0FiWMoPQ3Oddnoh6tlT4djnsc9IW0Tzk6ozvQL7sKdYgO8 ZlIpkBqQQfpSHzwPu9EkOFggPWB9WtP3IajQ0lt1LovqMug4C8APRC2/1cvi+GUIRwjVsop0 ukhlLTTJd3/S4Muh3s87M4Rdek1xpOiMKjYOVaxmhQQ91oz971zJuJJWpX7uUQiXx9oEwCDW TvI5yEuqYLsMUwx3d2iFTr+HbtlBJmF+Vguyrn/a3vFK8P/TH9fMvNeTdln9SuOOa1SAMMcy czOpBYg9RpzNLshUJVrhKzugT59Rl2wsNQsQCUkzgF3f8cZHJyl+8x6t0nuM9LTkMv13YIXS Mde3UOD2EaBhmeIqvC/adQHxpNudvxM1viFJDnTnzsFNBFgnLnwBEAC7kzsZqjBRPonnr/63 C98FSa3LikvqQWygmPSCC9DsFX/fB0CSXIHTrHQ4a7lXdfZyTZcGdxXN+MC8O8thjvVq6WYm CpyOJ/bq4SxOa9cnQSJ5SP9VCmVoDN/3T4ybXFzLAt756kfQ5jsVuP0m6iQ4z918zhZXk+Mo qdwGjYTxsBD02a7m1aeYafyaI2mZ+vdEy0cDhV4PDXI6ThLNAavTPji6ZrBdH5a4LMg30u8v kkNe0eCKvU+0cWb2VQIeddMhhiGSBE2Dv+A4eNe1VZvoGpLDlYdnoHraVFL2GHNFGymj/uRf 1hja5kW9Rekisqby5SpGABwrFFEs7ABpfYG0IRBKbjjG1Cqdfe/R6ETJFvvNOOpCKPAWeqYf Isxv4OHWTmhKihhIanYWCAe1MDLRRbj7UrOTZeia2WJ4v58xbU5rVQoHI/Tzaq86rXzRWITc 5w+kresMad0zpvQ900BdHc8ATNY2aW/Fr5it5OqMvIW6Y4gc8Z95MkQPVc8vj3WzfxuWtZNK 6Wbv4r6Qbiwg1RpY1JoEIoF4OsZJOVMQaB6ezD7xvaa2eY6nRGtq9SoJxo2qvlSbLlKq8NdH VYHhtTbpQ1NfrEJfv5sLX5W5IpoYww48bFYH67+7r1f/W3voBptSgE7qnYAm6Em9bEAKOQEX 8BXwoa54fn03z6TyhwARAQABwsFkBBgBCAAPBQJYJy58AhsMBQkJZgGAAAoJEMEREt5vqeH5 6PcP+JvrMM7ZM8UlnbrY4Er9psPj3ayllRhQFA9h6GNUKYuSzSxOrPaT96s8KUGMCr4jrn1S WFmeeNLLOgSJmQRicMh6LmnKq6WY6UaOfn7Y9O62NUjXfEI3Bw4ID36YCdQ+CJd14r0YOf4M 5F50bvHV3lbzD9TXZPxecHKC2ZUMBbT37tsckWCLL3lzKMsqQLwBUmgBl1NIUc7gyXxiNyxb 6SPVF1NguDDM438mcg9jSRAyjgAk6POUEM8YIXkw0Gg6HF1tNMJJ1xTMBCLYl6fHTtsxJpf9 yo+Hnw346hqYzXn4ytHJ49Ngcre8uhqM1l8iMpa17tEjfalkc1FWR9/qvoowOKtxpvblsy3a YzeEFgIomhLzISz6IafQ3S7Mt5AFlqwN/qQHx0k2V66GzDG0ngZBPROP1sXSpdJzO0zbJQFn MZE3f+y8vXMcE/MBXR7kAdYYApiEMQzVxy9TdQDU3lGLptcPZ1IOntTNFFrvp5NwsKi+6C9i mXtd5kJ1PwhcJYW3/ov/490l60C5SFUL/RZ/NOW8SHFaPcqlGcqIlexFKbzrMQwmYXo95jWB eZ0Qn+raxCUFZNGiwtusyQGBMcpHVJUanOCNd1z4ZbfmhUjDJKC/7YWDunvaDRSukGiRCl6J s8caqXHiVZjx+s76iWzm6AHRP5jg9D6EtTOrGiE= Message-ID: <38366d2c-12e6-39f1-c605-cb7ff4f1354e@m5p.com> Date: Wed, 4 Apr 2018 13:00:09 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ja0Kbs71x11GHcEIey9D1hHoIwS60nCfy" X-Spam-Status: No, score=0.2 required=10.0 tests=HELO_MISC_IP, RP_MATCHES_RCVD autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mattapan.m5p.com X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mailhost.m5p.com [IPv6:2001:470:1f07:15ff::f7]); Wed, 04 Apr 2018 13:01:42 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 17:01:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ja0Kbs71x11GHcEIey9D1hHoIwS60nCfy Content-Type: multipart/mixed; boundary="23lrORpkBjyj0XYEAMvDhKXKP049UBfvX"; protected-headers="v1" From: George Mitchell To: freebsd-stable@freebsd.org Message-ID: <38366d2c-12e6-39f1-c605-cb7ff4f1354e@m5p.com> Subject: Re: kern.sched.quantum: Creepy, sadistic scheduler References: <9FDC510B-49D0-4722-B695-6CD38CA20D4A@gmail.com> In-Reply-To: --23lrORpkBjyj0XYEAMvDhKXKP049UBfvX Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/04/18 10:34, Peter wrote: > [...] It does not make sense to me if now we state that > we cannot do it anymore because single-CPU is uncommon today. > [...] +1. -- George --23lrORpkBjyj0XYEAMvDhKXKP049UBfvX-- --ja0Kbs71x11GHcEIey9D1hHoIwS60nCfy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAlrFBKAACgkQwRES3m+p 4fnklQ/8D+gdNiBXjHFUzDkGisH5/gkCBGOGVPC+YZGzNRl+SmGjF60Xbq0VEUgM 1zb93sBSBSALF3LHRmqeTgfh/2EiSToKa4uvO2d8ayk1tLpduS6eiV9PJIQD87dC +osLH2yrtfStP2Pg931m/IucJBojhVjaZfLeKfq7ZRjwkLUWZyY72yG178W0X4YC ctYqRr3m8ff6hZQFQSjL7uy1TI2Tgt4u3sopBOpzDvgO62ZmmxJSSS6nciPmpNgK HeTsyL/q1oco+YIoCOfb03cAyvyQiTt7KBJMVm23i+U9n0dppsK/YzTWwUA5Zt5o dKgMpHleyHZ7+k2B1j7Z4v1hYc3kXyR+ylccDwd19x8I3FyOR2HyIZKj3UEGsMKs rBYo1/W4NvhVzTVYtpc5RFfO/N9v2GzB/ENOG0/ZIUmnvk8J3gCex6NUXSk64kmg nEuVXFV8KCy1i4EjvH3x+zO0WmpF9ExPEv57RyWLfz70qVYTCQiAfFDelYErcrJh 6Kd8yEfVZyzvFnioH6lFbNekz1v/1PLgoBcWU34l1ecYy+eO6fXTr59J8VaIsAbx ELTk8xgP968q89jLR8irLpoh/Da5hnN3/rgLmanPF/uwUw31HYe7m94kLOU+rcKV Wxod/rbjYbbeTurph+eFRrRe8O5ngjJtestmjZ2yJ34DAH25+4E= =toWY -----END PGP SIGNATURE----- --ja0Kbs71x11GHcEIey9D1hHoIwS60nCfy-- From owner-freebsd-stable@freebsd.org Wed Apr 4 17:48:37 2018 Return-Path: Delivered-To: freebsd-stable@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 AB68DF9FD9B for ; Wed, 4 Apr 2018 17:48:37 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1854187FD1 for ; Wed, 4 Apr 2018 17:48:36 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-wm0-f67.google.com with SMTP id t67so23711683wmt.0 for ; Wed, 04 Apr 2018 10:48:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Fp40WbX7v9Bos3YSYWSpTpJxOzZic/BNOxdqYLWGGTY=; b=douRp0LOHMxeBHe5PJf/uuqR22cQAoSBmJzLUAEVubpcTD1bBw8VFRKcZvFRNuZBm3 m5C3x0OaIzWMKj+VXHqf3JNnbakCwoZNjoc6w/WHwZ3jZTGp4s6g54Dqe9jetNTNRmrj Gj0Rjo4/WrEq22oJybAWsgxemetuC8VsoQvSG7mr99kCSOb8FzdCjBeO1iJ1W1VMiceJ UmLnB03qQAKJjIB2W6tz3hPpB2/8M3cblrYJ6uytu4xF3fe+yT4xWiXJmCdjA7xKuOWk LLpZsDAVGkDNDzxOQpzIkPAA2EKNgd7T1i7LzfLZ/BajyYx3PwIyKkIa6Uxc4emhUqg6 QCGQ== X-Gm-Message-State: ALQs6tDw2Ybb7f9D2YWGSljtKeONBRlUZG/+sLumtkERY5c68GB2VqtV LoUUPIsOaq1dUzAlqzT2Tr6nyMKt X-Google-Smtp-Source: AIpwx49bNikbR2moZlqNqNjTjO5O8BUMSMmXVDapELLmSI12obI1rY6F4HW7994yN5XGxbJ5NGS3Mg== X-Received: by 10.46.135.134 with SMTP id n6mr12246198lji.52.1522864110193; Wed, 04 Apr 2018 10:48:30 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id q28-v6sm1107536lfb.84.2018.04.04.10.48.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 10:48:29 -0700 (PDT) Subject: Re: kern.sched.quantum: Creepy, sadistic scheduler To: Peter , freebsd-stable@FreeBSD.ORG References: From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <6883cf2d-207e-21ae-8d55-c768f0b72a73@FreeBSD.org> Date: Wed, 4 Apr 2018 20:48:28 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 17:48:37 -0000 On 04/04/2018 03:52, Peter wrote: > Lets run an I/O-active task, e.g, postgres VACUUM that would > continuousely read from big files (while doing compute as well [1]): Not everyone has a postgres server and a suitable database. Could you please devise a test scenario that demonstrates the problem and that anyone could run? -- Andriy Gapon From owner-freebsd-stable@freebsd.org Wed Apr 4 20:13:27 2018 Return-Path: Delivered-To: freebsd-stable@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 3B9BEF72D9A for ; Wed, 4 Apr 2018 20:13:27 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 90B1B71582 for ; Wed, 4 Apr 2018 20:13:26 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.sub.de (8.15.2/8.15.2) with ESMTPS id w34KD5VE018433 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 4 Apr 2018 22:13:05 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.15.2/8.15.2/Submit) with UUCP id w34KD5fl018432 for freebsd-stable@FreeBSD.ORG; Wed, 4 Apr 2018 22:13:05 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id w34JaE00046332 for ; Wed, 4 Apr 2018 21:36:14 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id w34JY3Hh046061 for ; Wed, 4 Apr 2018 21:34:04 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id w34JY3Yl046056 for freebsd-stable@FreeBSD.ORG; Wed, 4 Apr 2018 21:34:03 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: Re: kern.sched.quantum: Creepy, sadistic scheduler Date: Wed, 4 Apr 2018 21:25:49 +0200 Organization: even some more stinky socks Message-ID: References: <6883cf2d-207e-21ae-8d55-c768f0b72a73@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 4 Apr 2018 19:26:26 -0000 (UTC) Injection-Info: oper.dinoex.de; logging-data="44897"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48 In-Reply-To: <6883cf2d-207e-21ae-8d55-c768f0b72a73@FreeBSD.org> Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.sub.de [194.45.71.2]); Wed, 04 Apr 2018 22:13:06 +0200 (CEST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 20:13:27 -0000 Andriy Gapon wrote: > On 04/04/2018 03:52, Peter wrote: >> Lets run an I/O-active task, e.g, postgres VACUUM that would >> continuousely read from big files (while doing compute as well [1]): > > Not everyone has a postgres server and a suitable database. > Could you please devise a test scenario that demonstrates the problem and that > anyone could run? > Andriy, and maybe nobody anymore has such old system that is CPU-bound instead of IO-bound. I'd rather think about reproducing it on my IvyBridge. I know for sure that it is *not* specifically dependent on postgres. What I posted was the case when an endless-loop piglet starves a postgres VACUUM - and there we see a very pronounced effect of almost factor 100. When I first clearly discovered it (after a long time of belly-feeling that something behaves strange), it was postgres pg_dump (which does compression, i.e. CPU-bound) as the piglet starving an bacula-fd backup that would scan the filesystem. So, there is a general rule: we have one process that is a CPU-hog, and another process that does periodic I/O (but also *some* compute). and -important!- nothing else. If we understand the logic of the scheduler, that information should already suit for some logical verification *eg* - but I will see if I get it reprocuved on the IvyBridge machine and/or see if I get a testcase together. May take a while. P. From owner-freebsd-stable@freebsd.org Wed Apr 4 20:53:28 2018 Return-Path: Delivered-To: freebsd-stable@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 2E66FF757E4 for ; Wed, 4 Apr 2018 20:53:28 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 76A1573383 for ; Wed, 4 Apr 2018 20:53:27 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.sub.de (8.15.2/8.15.2) with ESMTPS id w34Kr7O2031122 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 4 Apr 2018 22:53:08 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.15.2/8.15.2/Submit) with UUCP id w34Kr7MB031121 for freebsd-stable@FreeBSD.ORG; Wed, 4 Apr 2018 22:53:07 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id w34KmFfL056615 for ; Wed, 4 Apr 2018 22:48:15 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id w34Kjv3d056310 for ; Wed, 4 Apr 2018 22:45:58 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id w34KjvK4056309 for freebsd-stable@FreeBSD.ORG; Wed, 4 Apr 2018 22:45:57 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: Re: kern.sched.quantum: Creepy, sadistic scheduler Date: Wed, 4 Apr 2018 22:42:22 +0200 Organization: even some more stinky socks Message-ID: References: <6883cf2d-207e-21ae-8d55-c768f0b72a73@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 4 Apr 2018 20:42:22 -0000 (UTC) Injection-Info: oper.dinoex.de; logging-data="55716"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48 In-Reply-To: <6883cf2d-207e-21ae-8d55-c768f0b72a73@FreeBSD.org> Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.sub.de [194.45.71.2]); Wed, 04 Apr 2018 22:53:09 +0200 (CEST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 20:53:28 -0000 Andriy Gapon wrote: > Not everyone has a postgres server and a suitable database. > Could you please devise a test scenario that demonstrates the problem and that > anyone could run? > Alright, simple things first: I can reproduce the effect without postgres, with regular commands. I run this on my database file: # lz4 2058067.1 /dev/null And have this as throughput: pool alloc free read write read write cache - - - - - - ada1s4 7.08G 10.9G 889 0 7.07M 42.3K PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 51298 root 87 0 16184K 7912K RUN 1:00 51.60% lz4 I start the piglet: $ while true; do :; done And, same effect: pool alloc free read write read write cache - - - - - - ada1s4 7.08G 10.9G 10 0 82.0K 0 PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 1911 admin 98 0 7044K 2860K RUN 65:48 89.22% bash 51298 root 52 0 16184K 7880K RUN 0:05 0.59% lz4 It does *not* happen with plain "cat" instead of "lz4". What may or may not have an influence on it: the respective filesystem is block=8k, and is 100% resident in l2arc. What is also interesting: I started trying this with "tar" (no effect, behaves properly), then with "tar --lz4". In the latter case "tar" starts "lz4" as a sub-process, so we have three processes in the play - and in that case the effect happens, but to lesser extent: about 75 I/Os per second. So, it seems quite clear that this has something to do with the logic inside the scheduler. From owner-freebsd-stable@freebsd.org Thu Apr 5 05:55:56 2018 Return-Path: Delivered-To: freebsd-stable@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 DB7B9F8CEF4 for ; Thu, 5 Apr 2018 05:55:56 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 61DF86AB27 for ; Thu, 5 Apr 2018 05:55:56 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w355tNB3034925 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Apr 2018 07:55:24 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: pmc@citylink.dinoex.sub.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w355tJKq014822 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Apr 2018 12:55:19 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: kern.sched.quantum: Creepy, sadistic scheduler To: Peter , freebsd-stable@FreeBSD.ORG References: <9FDC510B-49D0-4722-B695-6CD38CA20D4A@gmail.com> <8cfdb8a3-86a0-17ba-1e41-ff1912a30ee9@m5p.com> From: Eugene Grosbein Message-ID: <5AC5BA42.1010006@grosbein.net> Date: Thu, 5 Apr 2018 12:55:14 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 05:55:57 -0000 04.04.2018 21:16, Peter wrote: > // With nCPU compute-bound processes running, with SCHED_ULE, any other > // process that is interactive (which to me means frequently waiting for > // I/O) gets ABYSMAL performance -- over an order of magnitude worse > // than it gets with SCHED_4BSD under the same conditions. -- > https://lists.freebsd.org/pipermail/freebsd-stable/2011-December/064984.html > > And this describes quite exactly what I perceive. > Now, I would like to ask: what has been done about this issue? I see no reasons to use SHED_ULE for such single core systems and use SCHED_BSD. From owner-freebsd-stable@freebsd.org Thu Apr 5 14:08:29 2018 Return-Path: Delivered-To: freebsd-stable@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 6E97FF88315 for ; Thu, 5 Apr 2018 14:08:29 +0000 (UTC) (envelope-from eugene@zhegan.in) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D03A57DB4D for ; Thu, 5 Apr 2018 14:08:28 +0000 (UTC) (envelope-from eugene@zhegan.in) Received: from bsdrookie.norma.com. (asterisk.enaza.ru [91.237.76.254]) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPS id w35E8MNe034336 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 5 Apr 2018 19:08:23 +0500 (YEKT) (envelope-from eugene@zhegan.in) To: freebsd-stable@FreeBSD.ORG From: "Eugene M. Zheganin" Subject: TRIM, iSCSI and %busy waves Message-ID: <92b92a3d-3262-c006-ed5a-dc2f9f4a5cb9@zhegan.in> Date: Thu, 5 Apr 2018 19:08:22 +0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spamd-Result: default: False [-998.10 / 25.00] WHITELISTED_IPS(-999.00)[91.237.76.254] AUTH_NA(1.00)[] RCVD_COUNT_TWO(0.00)[2] MID_RHS_MATCH_FROM(0.00)[] DMARC_NA(0.00)[zhegan.in] FROM_EQ_ENVFROM(0.00)[] ARC_NA(0.00)[] ASN(0.00)[asn:57973, ipnet:91.237.76.0/24, country:RU] FROM_HAS_DN(0.00)[] R_SPF_NA(0.00)[] TO_MATCH_ENVRCPT_ALL(0.00)[] TO_DN_NONE(0.00)[] MIME_GOOD(-0.10)[text/plain] RCPT_COUNT_ONE(0.00)[1] RCVD_TLS_ALL(0.00)[] R_DKIM_NA(0.00)[] IP_SCORE(0.00)[ip: (-9.89), ipnet: 91.237.76.0/24(-7.82), asn: 57973(-4.89), country: RU(0.12)] X-Rspamd-Server: localhost X-Rspamd-Scan-Time: 0.85 X-Rspamd-Queue-ID: w35E8MNe034336 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 14:08:29 -0000 Hi, I have a production iSCSI system (on zfs of course) with 15 ssd disks and it's often suffering from TRIMs. Well, I know what TRIM is for, and I know it's a good thing, but sometimes (actually often) I'm seeing my disks in gstat are overwhelmed by the TRIM waves, this looks like a "wave" of 20K 100%busy delete operations starting on first pool disk, then reaching second, then third,... - at the time it reaches the 15th disk the first one if freed from TRIM operations, and in 20-40 seconds this wave begins again. I'm also having a couple of iSCSI issues that I'm dealing through bounty with, so may be this is related somehow. Or may be not. Due to some issues in iSCSI stack my system sometimes reboots, and then these "waves" are stopped for some time. So, my question is - can I fine-tune TRIM operations ? So they don't consume the whole disk at 100%. I see several sysctl oids, but they aren't well-documented. P.S. This is 11.x, disks are Toshibas, and they are attached via LSI HBA. Thanks. Eugene. From owner-freebsd-stable@freebsd.org Thu Apr 5 14:29:00 2018 Return-Path: Delivered-To: freebsd-stable@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 AFD33F89ABA for ; Thu, 5 Apr 2018 14:29:00 +0000 (UTC) (envelope-from marcnarc@gmail.com) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 485D37ECD8 for ; Thu, 5 Apr 2018 14:29:00 +0000 (UTC) (envelope-from marcnarc@gmail.com) Received: by mail-qk0-x22a.google.com with SMTP id w6so26523354qkb.4 for ; Thu, 05 Apr 2018 07:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=1ug7qLkV/wW3MCjqLvdNBgM4ybMuK9ei7wOX8sXzDAU=; b=eVhGdlvqgYJfp6ATLwkPHM5LJlmwyx/8rWP6iGOGR/WCHPApiuiOmuhMAArmcC+1rm PQtkXupionvoPn+OEPKXl/U5jczTwPyHGtHwUJ8Hh1uVRWIQjMLBLKEkAs6QW2vi5B+h +0/fRk0IXHPkuUxubpI0Tl65uydq3yRw+agmL12URqPdOcEzQEYdwCZ0jdudf7/8giOn 1xCkvEsuRVWpsOzyBn9Ulza8mNpEDQ5FqpArKqhnKF7Viqwd0gsmU9LBdGn2+JJIQcPO w+aAdZZD3wF7sfOGSyJgbh5qNglZa+0RPs6Aauh0m8pP3QnAGdAGwPlMbM4iY5pQY4UY N7HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=1ug7qLkV/wW3MCjqLvdNBgM4ybMuK9ei7wOX8sXzDAU=; b=D4d9Q0kwucMuu4/lbgJvooh6VI4JcQPNtUXQ7UC9Y7jBX0Ks1ZQXrMVvDSJfdPCvNN 64vl14ERScijaD8J/+dc4iHbXNH6BlXBhgqVXgf2aCTskhgM1Zc7aqIIqSvAnZkoDsNi Q3hvGEK41/seFsc0UO1Ew+3iI9YJDDWRkg3PjQ2kax0Exhl/DkM9jgD5jmGesgFBPuOA lrfU7/7I8k+PyAays5nSptionVvUIpAS9CUgScnAVTbN5lTZ3jVEtB98jHeTf9JmpULD E207Pdi6CBpJ8OzKu8M2hXcFpmAGEicGIF94sTB059tjN5TQR7b/jNUsvBq8ED/OOmbE L7JQ== X-Gm-Message-State: ALQs6tDx29SWJ3c/PAGl1h8UYwKQgUccrVD/dyaLSeA+EZjXzwXQwKzE Cl23Itf3l7VBYRCyZ5qG6g8= X-Google-Smtp-Source: AIpwx49O/eFnhR9ZQeyzI2TxgRxwF+S6pNxjvFG+yvlAR99kRptei+84c+bjxVIiN9OqQjNiJnbfng== X-Received: by 10.55.109.129 with SMTP id i123mr29981178qkc.114.1522938539830; Thu, 05 Apr 2018 07:28:59 -0700 (PDT) Received: from [10.10.1.32] ([192.252.130.194]) by smtp.gmail.com with ESMTPSA id q19sm6590637qta.12.2018.04.05.07.28.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Apr 2018 07:28:58 -0700 (PDT) To: freebsd-stable@FreeBSD.ORG From: Marc Branchaud Subject: Problems with ifconfig when starting all jails after 10.3 -> 10.4 upgrade Message-ID: <45483fb3-bd94-10f1-a75c-3a035ec69cfa@gmail.com> Date: Thu, 5 Apr 2018 10:28:58 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 14:29:00 -0000 Hi all, I just upgraded from 10.3 to 10.4, and "/etc/rc.d/jail start" is having problems starting all of my jails: # /etc/rc.d/jail start Starting jails:xipbuild_3_3: created ifconfig:: bad value jail: xipbuild_3_3_8: /sbin/ifconfig lo1 inet 10.1.1.38/32 alias: failed xipbuild_3_4: created ifconfig:: bad value jail: xipbuild_4_0: /sbin/ifconfig lo1 inet 10.1.1.5/32 alias: failed xipbuild: created xipbuild_4_9: created ifconfig:: bad value jail: xipbuild9: /sbin/ifconfig lo1 inet 10.1.1.209/32 alias: failed . This worked fine in 10.3. I can individually start each jail, e.g. "/etc/rc.d/jail start xipbuild9". All the jails configure the same set of parameters. Here's my jail.conf: --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- xipbuild_3_3 { path="/usr/build-jails/jails/3.3"; host.hostname="xipbuild_3_3"; ip4.addr="10.1.1.3/32"; allow.chflags; allow.mount; mount.devfs; persist; mount="/usr/home /usr/build-jails/jails/3.3/usr/home nullfs rw 0 0"; interface="lo1"; } xipbuild_3_3_8 { path="/usr/build-jails/jails/3.3.8"; host.hostname="xipbuild_3_3_8"; ip4.addr="10.1.1.38/32"; allow.chflags; allow.mount; mount.devfs; persist; mount="/usr/home /usr/build-jails/jails/3.3.8/usr/home nullfs rw 0 0"; interface="lo1"; } xipbuild_3_4 { path="/usr/build-jails/jails/3.4"; host.hostname="xipbuild_3_4"; ip4.addr="10.1.1.4/32"; allow.chflags; allow.mount; mount.devfs; persist; mount="/usr/home /usr/build-jails/jails/3.4/usr/home nullfs rw 0 0"; interface="lo1"; } xipbuild_4_0 { path="/usr/build-jails/jails/4.0"; host.hostname="xipbuild_4_0"; ip4.addr="10.1.1.5/32"; allow.chflags; allow.mount; mount.devfs; persist; mount="/usr/home /usr/build-jails/jails/4.0/usr/home nullfs rw 0 0"; interface="lo1"; } xipbuild { path="/usr/build-jails/jails/latest"; host.hostname="xipbuild"; ip4.addr="10.1.1.200/32"; allow.chflags; allow.mount; mount.devfs; persist; mount="/usr/home /usr/build-jails/jails/latest/usr/home nullfs rw 0 0"; interface="lo1"; } xipbuild_4_9 { path="/usr/build-jails/jails/4.9"; host.hostname="xipbuild_4_9"; ip4.addr="10.1.1.90/32"; allow.chflags; allow.mount; mount.devfs; persist; mount="/usr/home /usr/build-jails/jails/4.9/usr/home nullfs rw 0 0"; interface="lo1"; } xipbuild9 { path="/usr/build-jails/jails/latest9"; host.hostname="xipbuild9"; ip4.addr="10.1.1.209/32"; allow.chflags; allow.mount; mount.devfs; persist; mount="/usr/home /usr/build-jails/jails/latest9/usr/home nullfs rw 0 0"; interface="lo1"; } --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- I use ipnat to give the jails network access. Here's ipnat.rules: --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- map em0 10.1.1.0/24 -> 0/32 proxy port ftp ftp/tcp map em0 10.1.1.0/24 -> 0/32 --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- And here's my rc.conf: --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- # Generated by Ansible # hostname must be FQDN hostname="devastator.xiplink.com" zfs_enable="False" # FIXME: previously auto-created? ifconfig_lo1="create" ifconfig_em0="DHCP SYNCDHCP" network_interfaces="em0" gateway_enable="YES" # Prevent rpc rpcbind_enable="NO" # Prevent sendmail to try to connect to localhost sendmail_enable="NO" sendmail_submit_enable="NO" sendmail_outbound_enable="NO" sendmail_msp_queue_enable="NO" # Bring up sshd, it takes some time and uses some entropy on first startup sshd_enable="YES" netwait_enable="YES" netwait_ip="10.10.0.35" netwait_if="em0" jenkins_swarm_enable="YES" jenkins_swarm_opts="-executors 8" # --- Build jails --- build_jails_enable="YES" jail_enable="YES" # Set rules in /etc/ipnat.rules ipnat_enable="YES" # Set interface name for ipnat network_interfaces="${network_interfaces} lo1" # Each jail needs to specify its IP address and mask bits in ipv4_addrs_lo1 ipv4_addrs_lo1="10.1.1.1/32" jail_chflags_allow="yes" varmfs="NO" --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- Any insight would be deeply appreciated! M. From owner-freebsd-stable@freebsd.org Thu Apr 5 14:57:45 2018 Return-Path: Delivered-To: freebsd-stable@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 B7E10F8B917 for ; Thu, 5 Apr 2018 14:57:45 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33202801E7 for ; Thu, 5 Apr 2018 14:57:45 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x233.google.com with SMTP id b127so6557063wmf.5 for ; Thu, 05 Apr 2018 07:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=CcrTA07kUfia3Dre9WpAHdumM4Dkwykb0Gd0anpIX0s=; b=PNk/ci728rYmtgdPJ/5k8g1mjKI6yKOfe1i1Z9rpSyYfNkAmpGgiASWd5OnwVFqGUs 7a/fdCAgbktrp8WIVG3JvcLeS/NdN7bCKJ1OJDcquZDIAfRADrOOjZlf4mncN0U9LEnS dJCwgprdK6hKjGuZv2XfcMeYqy8zSdzLE7zuMJdWCCbYJUlssgJS4X8j5Rd3H5iyKOpg 9VlrLqwaGAqqYZ4IAgNTMNaia6ZfUu3tpVN2eH/M0Qszt0QSz47ss9Wkz5weH3D/4xnj OMmrBipF+g1vfxE8flt8FN2spc0P8hDPdULOOEIe63YcyS8bVELhkVWAmHR943cMn85J GccQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=CcrTA07kUfia3Dre9WpAHdumM4Dkwykb0Gd0anpIX0s=; b=gGWr9Q/dFfpy4b1V5MrLYkhra8eEMOheJwFRoYGSBLVPorBzDQC0T1I8lW3MzV/nDa dyoJc4PfZ5ePnCbV7dWdzxo9sZ2C6eRQHJRONMKUryTFeQTghSIW8/A9uT0D60EQno9Z qQqTI7Sx6tDUrkQN/DSpGgwdUENO00n1CsgoovC+KbHESkt91FDW5ycvnHr6N8YfJWmA hAhpaZ2vDELFn18cBPklisUoOjzfmkjcwMkkd+nYajxmhDkhLD4q6mOrUr1cG4xkCoCM 77shabKxJNideWvReGTIB1qDwLusOsWe7aLfv28b3VQC2aqIWxodNpKKalzbWtLpgCEj ay1g== X-Gm-Message-State: AElRT7EhYd+lfKojmknbl5A4wxzxxWf4Z6kNuk07LH0H5EGcwZcCJRhf 5FeMmVYpFgBbInJQAkKrgYkJ2gwy7OI= X-Google-Smtp-Source: AIpwx49tFeFvxirOOrCALHlFHofo3+Q9ABxPhyU5Wvbg9YMYFoFTp5HmWktv4+/ET51WuwdYoykoMQ== X-Received: by 10.28.213.209 with SMTP id m200mr10549778wmg.83.1522940263643; Thu, 05 Apr 2018 07:57:43 -0700 (PDT) Received: from [10.10.1.111] ([185.97.61.1]) by smtp.gmail.com with ESMTPSA id n143sm9317634wmd.29.2018.04.05.07.57.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Apr 2018 07:57:42 -0700 (PDT) Subject: Re: TRIM, iSCSI and %busy waves To: freebsd-stable@freebsd.org References: <92b92a3d-3262-c006-ed5a-dc2f9f4a5cb9@zhegan.in> From: Steven Hartland Message-ID: <2daf0677-3feb-6c4c-38d3-ed552f1a3cf0@multiplay.co.uk> Date: Thu, 5 Apr 2018 15:57:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <92b92a3d-3262-c006-ed5a-dc2f9f4a5cb9@zhegan.in> Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 14:57:46 -0000 You can indeed tune things here are the relevant sysctls: sysctl -a | grep trim |grep -v kstat vfs.zfs.trim.max_interval: 1 vfs.zfs.trim.timeout: 30 vfs.zfs.trim.txg_delay: 32 vfs.zfs.trim.enabled: 1 vfs.zfs.vdev.trim_max_pending: 10000 vfs.zfs.vdev.trim_max_active: 64 vfs.zfs.vdev.trim_min_active: 1 vfs.zfs.vdev.trim_on_init: 1     Regards     Steve On 05/04/2018 15:08, Eugene M. Zheganin wrote: > Hi, > > I have a production iSCSI system (on zfs of course) with 15 ssd disks > and it's often suffering from TRIMs. > > Well, I know what TRIM is for, and I know it's a good thing, but > sometimes (actually often) I'm seeing my disks in gstat are > overwhelmed by the TRIM waves, this looks like a "wave" of 20K > 100%busy delete operations starting on first pool disk, then reaching > second, then third,... - at the time it reaches the 15th disk the > first one if freed from TRIM operations, and in 20-40 seconds this > wave begins again. > > I'm also having a couple of iSCSI issues that I'm dealing through > bounty with, so may be this is related somehow. Or may be not. Due to > some issues in iSCSI stack my system sometimes reboots, and then these > "waves" are stopped for some time. > > So, my question is - can I fine-tune TRIM operations ? So they don't > consume the whole disk at 100%. I see several sysctl oids, but they > aren't well-documented. > > P.S. This is 11.x, disks are Toshibas, and they are attached via LSI HBA. > > > Thanks. > > Eugene. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Thu Apr 5 15:00:17 2018 Return-Path: Delivered-To: freebsd-stable@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 B700CF8BB72 for ; Thu, 5 Apr 2018 15:00:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 75E2880465 for ; Thu, 5 Apr 2018 15:00:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x230.google.com with SMTP id 142-v6so3118119itl.5 for ; Thu, 05 Apr 2018 08:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=SAxHPIjWBlNDo9LcWJvRBv8ssFA6B3fIEb1os0KsN0A=; b=ouevNWiYQ8xZeJIrWqHPGnUhQHdETUrvLn7qLnwRmmO/NuhiNJjMOBzxTe/J+SRMCz xFHOP3VSk4sR5M5yaU4daGhatIxkQqBoso2EfCN3DQLa3z5z1L3LDyKTEu4/RWo3Ji9N yWOhVvc58USd67onH/rzKBN/sNHxKFdhTIqRLQK1gaUPf+WADmOBWCVlWk89QGvo+bDW U6T6CcoFRZt7e4Lca4856rrc4E5g5/G1OWciINRByCx3PScKEY0RaIFj3Bq/rKU3Felt qhxeB8NQ0n62MBvo0ZyOzeAgJPEVDZ3fUqGX3wyC7kzEVNPrhv2AWRdE3MIS3aKxubsx f5yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=SAxHPIjWBlNDo9LcWJvRBv8ssFA6B3fIEb1os0KsN0A=; b=gMLkVmWmEcFy81JJlgUsXD/3Uiv1UVKxe3yaOCfdfv+VFX4tcQUQZHkB76Yc8QYioI QtRRn0Leym5wRsvLSNiuj/fpUvz1yWVadrp6mQlpSlwOMk0Oj7+NfKAlvXHMH3PPvu8v sJseM+iH271UaKW4ztbhWOvJXr7p0RC5vV8KbkTE/43q1mjkBujsgUPYX8QIoRE+Resi xBWaA4Uhs8QLqQZbW/foRcg+CLxv8iWPMiFvGQSnd5rFvXEw63oRvya7k4HNsr5N2sxe 2xZkM+kE/IeW62DlrxCoTkj7qTiEcos1Jzb0H4XV0vcymaTOJKEHCxB7ppW6S3sboygy lbqA== X-Gm-Message-State: ALQs6tBsWh4kPOo4lnSFbOICh9bMYem1vdfH4O7XqhT+7uxggSs53CM0 K6M+FylvboNzoNc07Ec0ZWWPnwGcNb6BCccPi2nscQ== X-Google-Smtp-Source: AIpwx48JN1/LP11/fesKJIp1MWrVDrR/K2SkJ4b2LCemZ4wlsNXKUSbL1q1q50tfoAnJ6Qt8sXmIby10DkwXrJ1+564= X-Received: by 2002:a24:19c9:: with SMTP id b192-v6mr13816655itb.1.1522940416449; Thu, 05 Apr 2018 08:00:16 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Thu, 5 Apr 2018 08:00:15 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <92b92a3d-3262-c006-ed5a-dc2f9f4a5cb9@zhegan.in> References: <92b92a3d-3262-c006-ed5a-dc2f9f4a5cb9@zhegan.in> From: Warner Losh Date: Thu, 5 Apr 2018 09:00:15 -0600 X-Google-Sender-Auth: tZnYmkrkOiSratNsHiWpECCoVEw Message-ID: Subject: Re: TRIM, iSCSI and %busy waves To: "Eugene M. Zheganin" Cc: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 15:00:18 -0000 On Thu, Apr 5, 2018 at 8:08 AM, Eugene M. Zheganin wrote: > Hi, > > I have a production iSCSI system (on zfs of course) with 15 ssd disks and > it's often suffering from TRIMs. > > Well, I know what TRIM is for, and I know it's a good thing, but sometimes > (actually often) I'm seeing my disks in gstat are overwhelmed by the TRIM > waves, this looks like a "wave" of 20K 100%busy delete operations starting > on first pool disk, then reaching second, then third,... - at the time it > reaches the 15th disk the first one if freed from TRIM operations, and in > 20-40 seconds this wave begins again. > There's two issues here. First, %busy doesn't necessarily mean what you think it means. Back in the days of one operation at a time, it might have been a reasonable indicator that the drive is busy. However, today with queueing a 100% busy disk often can take additional load. The second problem is that TRIMs suck for a lot of reasons. FFS (I don't know about ZFS) sends lots of TRIMs at once when you delete a file. These TRIMs are UFS block sized, so need to be combined in the ada/da layer. The combining in the ada and da drivers isn't optimal, but implements a 'greedy' method where we pack as much as possible into each TRIM, which makes each TRIM take longer. Plus, TRIMs are non NCQ commands, so force a drain of all the other commands to do them. And we don't have any throttling in 11.x (at the moment), so they tend to flood the device and starve out other traffic when there's a lot of them. Not all controllers support NCQ trim (LSI doesn't at the moment, I don't think). With NCQ we only queue one at a time and that helps. I'm working on trim shaping in -current right now. It's focused on NVMe, but since I'm doing the bulk of it in cam_iosched.c, it will eventually be available for ada and da. The notion is to measure how long the TRIMs take, and only send them at 80% of that rate when there's other traffic in the queue (so if trims are taking 100ms, send them no faster than 8/s). While this will allow for better read/write traffic, it does slow the TRIMs down which slows down whatever they may be blocking in the upper layers. Can't speak to ZFS much, but for UFS that's freeing of blocks so things like new block allocation may be delayed if we're almost out of disk (which we have no signal for, so there's no way for the lower layers to prioritize trims or not). > I'm also having a couple of iSCSI issues that I'm dealing through bounty > with, so may be this is related somehow. Or may be not. Due to some issues > in iSCSI stack my system sometimes reboots, and then these "waves" are > stopped for some time. > > So, my question is - can I fine-tune TRIM operations ? So they don't > consume the whole disk at 100%. I see several sysctl oids, but they aren't > well-documented. > You might be able to set the delete method. > P.S. This is 11.x, disks are Toshibas, and they are attached via LSI HBA. > Which LSI HBA? Warner From owner-freebsd-stable@freebsd.org Thu Apr 5 15:15:50 2018 Return-Path: Delivered-To: freebsd-stable@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 6310BF8CC97 for ; Thu, 5 Apr 2018 15:15:50 +0000 (UTC) (envelope-from eugene@zhegan.in) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A225381021 for ; Thu, 5 Apr 2018 15:15:49 +0000 (UTC) (envelope-from eugene@zhegan.in) Received: from bsdrookie.norma.com. (asterisk.enaza.ru [91.237.76.254]) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPS id w35FFkJg037119 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 5 Apr 2018 20:15:46 +0500 (YEKT) (envelope-from eugene@zhegan.in) Subject: Re: TRIM, iSCSI and %busy waves To: freebsd-stable@freebsd.org References: <92b92a3d-3262-c006-ed5a-dc2f9f4a5cb9@zhegan.in> <2daf0677-3feb-6c4c-38d3-ed552f1a3cf0@multiplay.co.uk> From: "Eugene M. Zheganin" Message-ID: Date: Thu, 5 Apr 2018 20:15:45 +0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <2daf0677-3feb-6c4c-38d3-ed552f1a3cf0@multiplay.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spamd-Result: default: False [-998.10 / 25.00] WHITELISTED_IPS(-999.00)[91.237.76.254] AUTH_NA(1.00)[] RCVD_COUNT_TWO(0.00)[2] MID_RHS_MATCH_FROM(0.00)[] DMARC_NA(0.00)[zhegan.in] FROM_EQ_ENVFROM(0.00)[] ARC_NA(0.00)[] ASN(0.00)[asn:57973, ipnet:91.237.76.0/24, country:RU] FROM_HAS_DN(0.00)[] R_SPF_NA(0.00)[] TO_MATCH_ENVRCPT_ALL(0.00)[] TO_DN_NONE(0.00)[] MIME_GOOD(-0.10)[text/plain] RCPT_COUNT_ONE(0.00)[1] RCVD_TLS_ALL(0.00)[] R_DKIM_NA(0.00)[] IP_SCORE(0.00)[ip: (-9.89), ipnet: 91.237.76.0/24(-7.82), asn: 57973(-4.89), country: RU(0.12)] X-Rspamd-Server: localhost X-Rspamd-Scan-Time: 0.58 X-Rspamd-Queue-ID: w35FFkJg037119 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 15:15:50 -0000 Hello, On 05.04.2018 19:57, Steven Hartland wrote: > You can indeed tune things here are the relevant sysctls: > sysctl -a | grep trim |grep -v kstat > vfs.zfs.trim.max_interval: 1 > vfs.zfs.trim.timeout: 30 > vfs.zfs.trim.txg_delay: 32 > vfs.zfs.trim.enabled: 1 > vfs.zfs.vdev.trim_max_pending: 10000 > vfs.zfs.vdev.trim_max_active: 64 > vfs.zfs.vdev.trim_min_active: 1 > vfs.zfs.vdev.trim_on_init: 1 > Well, I've already seen these. How do I tune them ? The idea of just tampering with them and seeing what will happen doesn't look like a bright one to me. Do I increase or decrease them ? Which ones do I have to avoid ? Eugene. From owner-freebsd-stable@freebsd.org Thu Apr 5 15:18:15 2018 Return-Path: Delivered-To: freebsd-stable@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 82BCEF8CFCE for ; Thu, 5 Apr 2018 15:18:15 +0000 (UTC) (envelope-from eugene@zhegan.in) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EE19F812ED for ; Thu, 5 Apr 2018 15:18:14 +0000 (UTC) (envelope-from eugene@zhegan.in) Received: from bsdrookie.norma.com. (asterisk.enaza.ru [91.237.76.254]) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPS id w35FICC3037338 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 5 Apr 2018 20:18:12 +0500 (YEKT) (envelope-from eugene@zhegan.in) Subject: Re: TRIM, iSCSI and %busy waves To: FreeBSD-STABLE Mailing List References: <92b92a3d-3262-c006-ed5a-dc2f9f4a5cb9@zhegan.in> From: "Eugene M. Zheganin" Message-ID: <0e408973-375e-9489-77c5-b2bd2e2d1a87@zhegan.in> Date: Thu, 5 Apr 2018 20:18:12 +0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Spamd-Result: default: False [-998.10 / 25.00] WHITELISTED_IPS(-999.00)[91.237.76.254] AUTH_NA(1.00)[] RCVD_COUNT_TWO(0.00)[2] MID_RHS_MATCH_FROM(0.00)[] DMARC_NA(0.00)[zhegan.in] FROM_EQ_ENVFROM(0.00)[] ARC_NA(0.00)[] ASN(0.00)[asn:57973, ipnet:91.237.76.0/24, country:RU] FROM_HAS_DN(0.00)[] R_SPF_NA(0.00)[] TO_MATCH_ENVRCPT_ALL(0.00)[] TO_DN_ALL(0.00)[] MIME_GOOD(-0.10)[multipart/alternative, text/plain] RCPT_COUNT_ONE(0.00)[1] RCVD_TLS_ALL(0.00)[] R_DKIM_NA(0.00)[] IP_SCORE(0.00)[ip: (-9.89), ipnet: 91.237.76.0/24(-7.82), asn: 57973(-4.89), country: RU(0.12)] X-Rspamd-Server: localhost X-Rspamd-Scan-Time: 0.62 X-Rspamd-Queue-ID: w35FICC3037338 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 15:18:15 -0000 Hello, On 05.04.2018 20:00, Warner Losh wrote: > > I'm also having a couple of iSCSI issues that I'm dealing through > bounty with, so may be this is related somehow. Or may be not. Due > to some issues in iSCSI stack my system sometimes reboots, and > then these "waves" are stopped for some time. > > So, my question is - can I fine-tune TRIM operations ? So they > don't consume the whole disk at 100%. I see several sysctl oids, > but they aren't well-documented. > > > You might be able to set the delete method. Set it to what ? It's not like I'm seeing FreeBSD for the first time, but from what I see in sysctl - all of those "sysctl -a | grep trim" oids are numeric. > > P.S. This is 11.x, disks are Toshibas, and they are attached via > LSI HBA. > > > Which LSI HBA? > A SAS9300-4i4e one. Eugene. Thanks. From owner-freebsd-stable@freebsd.org Fri Apr 6 08:07:09 2018 Return-Path: Delivered-To: freebsd-stable@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 46BE2F8FDD5 for ; Fri, 6 Apr 2018 08:07:09 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D81A86BBAE for ; Fri, 6 Apr 2018 08:07:08 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.141] (unknown [192.148.167.11]) by proxypop01.sare.net (Postfix) with ESMTPA id 1C0499DDE51; Fri, 6 Apr 2018 09:58:52 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: TRIM, iSCSI and %busy waves From: Borja Marcos In-Reply-To: Date: Fri, 6 Apr 2018 09:58:52 +0200 Cc: "Eugene M. Zheganin" , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <8935E1F4-10DE-4621-8153-26AF851CC26E@sarenet.es> References: <92b92a3d-3262-c006-ed5a-dc2f9f4a5cb9@zhegan.in> To: Warner Losh X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 08:07:09 -0000 > On 5 Apr 2018, at 17:00, Warner Losh wrote: >=20 > I'm working on trim shaping in -current right now. It's focused on = NVMe, > but since I'm doing the bulk of it in cam_iosched.c, it will = eventually be > available for ada and da. The notion is to measure how long the TRIMs = take, > and only send them at 80% of that rate when there's other traffic in = the > queue (so if trims are taking 100ms, send them no faster than 8/s). = While > this will allow for better read/write traffic, it does slow the TRIMs = down > which slows down whatever they may be blocking in the upper layers. = Can't > speak to ZFS much, but for UFS that's freeing of blocks so things like = new > block allocation may be delayed if we're almost out of disk (which we = have > no signal for, so there's no way for the lower layers to prioritize = trims > or not). Have you considered "hard" shaping including discarding TRIMs when = needed? Remember that a TRIM is not a write, which is subject to a contract with = the application, but a better-if-you-do-it operation.=20 Otherwise, as you say, you might be blocking other operations in the = upper layers. I am assuming here that with many devices doing TRIMs is better than not = doing them. And in case of queue congestion doing *some* TRIMs should be better than = doing no TRIMs at all. Yep, not the first time I propose something of the sort, but my queue of = suggestions=20 to eventually discard TRIMs doesn=E2=80=99s implement the same method ;) Borja. From owner-freebsd-stable@freebsd.org Fri Apr 6 08:21:07 2018 Return-Path: Delivered-To: freebsd-stable@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 9A459F90E20 for ; Fri, 6 Apr 2018 08:21:07 +0000 (UTC) (envelope-from verogarcia@consult.com) Received: from consult.com (061093214146.ctinets.com [61.93.214.146]) by mx1.freebsd.org (Postfix) with ESMTP id 97EE66C829 for ; Fri, 6 Apr 2018 08:21:05 +0000 (UTC) (envelope-from verogarcia@consult.com) From: verogarcia@consult.com To: freebsd-stable@freebsd.org Subject: Re:Response Date: 06 Apr 2018 16:20:16 +0800 Message-ID: <20180406162016.8F7A6F0364E067B2@consult.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 08:21:07 -0000 Hello, Please, Let me know if you received my message, I have sent more=20 than 3 messages to you in the last 3 months without response,get=20 back to me Yours, Veronica Garcia From owner-freebsd-stable@freebsd.org Fri Apr 6 08:41:38 2018 Return-Path: Delivered-To: freebsd-stable@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 0A8D7F92ADA for ; Fri, 6 Apr 2018 08:41:38 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BB836DC3D for ; Fri, 6 Apr 2018 08:41:37 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: by mail-wr0-x233.google.com with SMTP id u46so696164wrc.11 for ; Fri, 06 Apr 2018 01:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EcOEvVGqnnf5utn3Yn3VRJYiHcYWWs1N0G6UaQEmLqs=; b=N4yHuRxcVXUQFS3Qx+lYjoNqdfAWTzlDOGL/jm6uh8dnEcUywoTOm9Hm1FX3FrbALm D1YCYRWFbroxLql0Hb+OIbxuVvF6Y2zXdwbFmyuWasAYhH8jak/twRqfiJ45aTIR8ZDL Xot5/7zhCbAYs9FMgddEU61VD0yVfMwBTjWv01PWtpaAM1UcmYbP58BBAytl7ehSzTnJ Y54pYYLUfPo7+AL/VD5GIly6kcOCE3EpYq7EfEzHdJrz9xz19fGH4pzAj3hucZhLvdxH Fp5lGDABtd4c90VAlnUBbe0sQlmajT9Ur2LRClNpw+PheZlte8KrZxt6j08WG5/jYCE3 z3IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EcOEvVGqnnf5utn3Yn3VRJYiHcYWWs1N0G6UaQEmLqs=; b=cCAbVxd4x9Mp7xq+IcgQPSUwq3TDLCpzXRCbwmosOal70Ax8sR3gRvbCjeKJHLLTYE UJkpGOQRR3nGug+sOAkn/OP59jWAOMV43rW1tCztvQ0S3MOC1FSxUviA/GOoiKQb7Ed/ s2qE1gVGDYsF8/VbhMdnB2bS03nF23aflnkC1Y5i9JzZT3d+cqbyoC7wFL8WeYaAFrzH VHE9JZEDcYJNMjs3xzyuiPBBxYgaHgIeJENNqeGI9I4R0iVx0eH+Y9c9jSFlY0ICKifr ryTMPCvNFbz+xzpH9paITGbyyaDtYEhfT3o3oat4XqGVJhS4R7W0tvFgCPtaqKM6J3x9 hhWg== X-Gm-Message-State: ALQs6tB/tkS7H3qfnqnjNG3qMbEJSTXVIGahOxfyUzwQZi/O8bOE9XDm 1Cxye26g+Z1+6VY96eN+VqbTwkoTubtpg0SPa8KbtPBd X-Google-Smtp-Source: AIpwx4+hPoRH1fKsPkEYt4oc8AqeVrQTDbR44cw7iRxEJpgoSSgUuGPF0WBWFgm+4nDNTunKBJ2hXzs1nN85DcZOri4= X-Received: by 2002:a19:c987:: with SMTP id z129-v6mr15484804lff.74.1523004096303; Fri, 06 Apr 2018 01:41:36 -0700 (PDT) MIME-Version: 1.0 References: <92b92a3d-3262-c006-ed5a-dc2f9f4a5cb9@zhegan.in> <8935E1F4-10DE-4621-8153-26AF851CC26E@sarenet.es> In-Reply-To: <8935E1F4-10DE-4621-8153-26AF851CC26E@sarenet.es> From: Steven Hartland Date: Fri, 06 Apr 2018 08:41:25 +0000 Message-ID: Subject: Re: TRIM, iSCSI and %busy waves To: Borja Marcos Cc: "Eugene M. Zheganin" , FreeBSD-STABLE Mailing List , Warner Losh Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 08:41:38 -0000 That is very hw and use case dependent. The reason we originally sponsored the project to add TRIM to ZFS was that in our case without TRIM the performance got so bad that we had to secure erase disks every couple of weeks as they simply became so slow they where unusable. Now admittedly that was a fair few years ago and hw has moved on since then, but the point remains that it=E2=80=99s not totally true that just no= t TRIMing is an option. On Fri, 6 Apr 2018 at 09:10, Borja Marcos wrote: > > > On 5 Apr 2018, at 17:00, Warner Losh wrote: > > > > I'm working on trim shaping in -current right now. It's focused on NVMe= , > > but since I'm doing the bulk of it in cam_iosched.c, it will eventually > be > > available for ada and da. The notion is to measure how long the TRIMs > take, > > and only send them at 80% of that rate when there's other traffic in th= e > > queue (so if trims are taking 100ms, send them no faster than 8/s). Whi= le > > this will allow for better read/write traffic, it does slow the TRIMs > down > > which slows down whatever they may be blocking in the upper layers. Can= 't > > speak to ZFS much, but for UFS that's freeing of blocks so things like > new > > block allocation may be delayed if we're almost out of disk (which we > have > > no signal for, so there's no way for the lower layers to prioritize tri= ms > > or not). > > Have you considered "hard" shaping including discarding TRIMs when needed= ? > Remember that a TRIM is not a write, which is subject to a contract with > the application, > but a better-if-you-do-it operation. > > Otherwise, as you say, you might be blocking other operations in the uppe= r > layers. > I am assuming here that with many devices doing TRIMs is better than not > doing them. > And in case of queue congestion doing *some* TRIMs should be better than > doing > no TRIMs at all. > > Yep, not the first time I propose something of the sort, but my queue of > suggestions > to eventually discard TRIMs doesn=E2=80=99s implement the same method ;) > > > Borja. > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@freebsd.org Fri Apr 6 09:05:36 2018 Return-Path: Delivered-To: freebsd-stable@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 71B6DF9452E for ; Fri, 6 Apr 2018 09:05:35 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu1176c.smtpx.saremail.com (cu1176c.smtpx.saremail.com [195.16.148.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A51D76EB9B for ; Fri, 6 Apr 2018 09:05:34 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.141] (unknown [192.148.167.11]) by proxypop02.sare.net (Postfix) with ESMTPA id BFF359DC8CE; Fri, 6 Apr 2018 10:56:12 +0200 (CEST) From: Borja Marcos Message-Id: <9AC3F9CE-B715-4894-B047-38758ACD913C@sarenet.es> Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: TRIM, iSCSI and %busy waves Date: Fri, 6 Apr 2018 10:56:11 +0200 In-Reply-To: Cc: "Eugene M. Zheganin" , FreeBSD-STABLE Mailing List , Warner Losh To: Steven Hartland References: <92b92a3d-3262-c006-ed5a-dc2f9f4a5cb9@zhegan.in> <8935E1F4-10DE-4621-8153-26AF851CC26E@sarenet.es> X-Mailer: Apple Mail (2.3445.6.18) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 09:05:36 -0000 > On 6 Apr 2018, at 10:41, Steven Hartland = wrote: >=20 > That is very hw and use case dependent. >=20 > The reason we originally sponsored the project to add TRIM to ZFS was = that in our case without TRIM the performance got so bad that we had to = secure erase disks every couple of weeks as they simply became so slow = they where unusable. >=20 > Now admittedly that was a fair few years ago and hw has moved on since = then, but the point remains that it=E2=80=99s not totally true that just = not TRIMing is an option. As far as I know, letting the device know that you have released a block = should be a Good Thing.=20 So I prefer to TRIM. I have also seen cases where not doing TRIMs = resulted in a terrible performance although modern SSDs should have better algorithms to deal with it.=20 But I have also seen bad cases of TRIM requests piling up and clogging = the queues for long periods of time. Admittedly it was a purely synthetic situation (running = bonnie++) but, again, performing operations like destroying a huge snapshot or dataset could trigger a = similar condition. It was especially nasty when I tried NVMEs. I mentioned this here: https://lists.freebsd.org/pipermail/freebsd-fs/2016-May/023134.html That=E2=80=99s why I think there is a mid point between the radical = approach of not doing TRIMs at all and clogging the queues with too many of them.=20 If the TRIM queue gets very large and the =E2=80=9Cmandatory=E2=80=9D = operations (read, writes, etc) begin to get large delays I think it=E2=80=99s safe to assume that *there is* a = problem and discarding at least part of those TRIMs could help to solve it.=20 A =E2=80=9CTRIM when you can=E2=80=9D should still be better than a = =E2=80=9CDon=E2=80=99t TRIM at all=E2=80=9D.=20 Cheers, Borja. P.S: Attaching the graphs that were lost. From owner-freebsd-stable@freebsd.org Fri Apr 6 09:13:40 2018 Return-Path: Delivered-To: freebsd-stable@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 5B6B1F94F14 for ; Fri, 6 Apr 2018 09:13:40 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EDD816F183 for ; Fri, 6 Apr 2018 09:13:39 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.141] (unknown [192.148.167.11]) by proxypop01.sare.net (Postfix) with ESMTPA id 2F57B9DD2AF; Fri, 6 Apr 2018 11:13:36 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: TRIM, iSCSI and %busy waves From: Borja Marcos In-Reply-To: <9AC3F9CE-B715-4894-B047-38758ACD913C@sarenet.es> Date: Fri, 6 Apr 2018 11:13:35 +0200 Cc: Steven Hartland , "Eugene M. Zheganin" , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: 7bit Message-Id: <5E892E10-1A9D-43ED-B5D8-7FA9D8C3E7DD@sarenet.es> References: <92b92a3d-3262-c006-ed5a-dc2f9f4a5cb9@zhegan.in> <8935E1F4-10DE-4621-8153-26AF851CC26E@sarenet.es> <9AC3F9CE-B715-4894-B047-38758ACD913C@sarenet.es> To: Borja Marcos X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 09:13:40 -0000 > On 6 Apr 2018, at 10:56, Borja Marcos wrote: > > P.S: Attaching the graphs that were lost. And, silly me, repeating the same mistakes over and over. http://frobula.crabdance.com:8001/publicfiles/OneBonnie.png http://frobula.crabdance.com:8001/publicfiles/TwoBonniesTimes.png http://frobula.crabdance.com:8001/publicfiles/TwoBonniesTput.png Sorry! Borja. From owner-freebsd-stable@freebsd.org Fri Apr 6 12:58:24 2018 Return-Path: Delivered-To: freebsd-stable@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 13028F836A6 for ; Fri, 6 Apr 2018 12:58:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9B83A79FAB for ; Fri, 6 Apr 2018 12:58:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 57EBAF836A5; Fri, 6 Apr 2018 12:58:23 +0000 (UTC) Delivered-To: stable@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 33426F836A3 for ; Fri, 6 Apr 2018 12:58:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C1A0479FA7 for ; Fri, 6 Apr 2018 12:58:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id EC9181F5A3 for ; Fri, 6 Apr 2018 12:58:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w36CwLbO077778 for ; Fri, 6 Apr 2018 12:58:21 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w36CwLwi077776 for stable@FreeBSD.org; Fri, 6 Apr 2018 12:58:21 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 227322] [patch] [iicbus] sys/modules/i2c/iicbus cannot be built outside of kernel build environment Date: Fri, 06 Apr 2018 12:58:21 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: easy, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ian@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status keywords bug_severity priority component assigned_to reporter cc attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 12:58:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227322 Bug ID: 227322 Summary: [patch] [iicbus] sys/modules/i2c/iicbus cannot be built outside of kernel build environment Product: Base System Version: 11.1-STABLE Hardware: Any OS: Any Status: New Keywords: easy, patch-ready Severity: Affects Some People Priority: --- Component: kern Assignee: ian@FreeBSD.org Reporter: eugen@freebsd.org CC: stable@FreeBSD.org Created attachment 192285 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D192285&action= =3Dedit The fix # cd /usr/src/sys/modules/i2c/iicbus && make cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc= =20=20 -I. -I/home/src/sys -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.iic_recover_bus.o -MTiic_recover_bus.o -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-comp= are -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-error-address-of-packed-member -mno-a= es -mno-avx -std=3Diso9899:1999 -c /home/src/sys/dev/iicbus/iic_recover_bus.c= -o iic_recover_bus.o /home/src/sys/dev/iicbus/iic_recover_bus.c:49:10: fatal error: 'opt_platfor= m.h' file not found #include "opt_platform.h" ^~~~~~~~~~~~~~~~ 1 error generated. *** Error code 1 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Fri Apr 6 13:09:38 2018 Return-Path: Delivered-To: freebsd-stable@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 703ECF845F9 for ; Fri, 6 Apr 2018 13:09:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E81907AAE5 for ; Fri, 6 Apr 2018 13:09:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 98158F845F6; Fri, 6 Apr 2018 13:09:37 +0000 (UTC) Delivered-To: stable@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 75FDAF845F5 for ; Fri, 6 Apr 2018 13:09:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F6767AAE0 for ; Fri, 6 Apr 2018 13:09:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 482551F702 for ; Fri, 6 Apr 2018 13:09:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w36D9aGF016046 for ; Fri, 6 Apr 2018 13:09:36 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w36D9aMM016045 for stable@FreeBSD.org; Fri, 6 Apr 2018 13:09:36 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 227323] [patch] [spi] sys/modules/spi/mx25l cannot be built outside of kernel build environment Date: Fri, 06 Apr 2018 13:09:35 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: easy, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: loos@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status keywords bug_severity priority component assigned_to reporter cc attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 13:09:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227323 Bug ID: 227323 Summary: [patch] [spi] sys/modules/spi/mx25l cannot be built outside of kernel build environment Product: Base System Version: 11.1-STABLE Hardware: Any OS: Any Status: New Keywords: easy, patch-ready Severity: Affects Some People Priority: --- Component: kern Assignee: loos@FreeBSD.org Reporter: eugen@freebsd.org CC: eadler@FreeBSD.org, ian@FreeBSD.org, stable@FreeBSD.org Created attachment 192286 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D192286&action= =3Dedit The fix # cd /usr/src/sys/modules/spi/mx25l && make cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc= =20=20 -I. -I/home/src/sys -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.mx25l.o -MTmx25l.o -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float=20 -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -W= all -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-comp= are -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-error-address-of-packed-member -mno-a= es -mno-avx -std=3Diso9899:1999 -c /home/src/sys/dev/flash/mx25l.c -o mx25l.o /home/src/sys/dev/flash/mx25l.c:30:10: fatal error: 'opt_platform.h' file n= ot found #include "opt_platform.h" ^~~~~~~~~~~~~~~~ 1 error generated. *** Error code 1 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Fri Apr 6 15:01:54 2018 Return-Path: Delivered-To: freebsd-stable@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 ED6F0F8C2D0 for ; Fri, 6 Apr 2018 15:01:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 965E57F9F6 for ; Fri, 6 Apr 2018 15:01:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x230.google.com with SMTP id t192-v6so5292415itc.1 for ; Fri, 06 Apr 2018 08:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GfZZy6f4ONCHbSs2Qu/jlgCAmgGx+8mdb0nvb50XMtI=; b=wGn1rFiGV+ldmxEJ8ZAkIwIpQXh9fASzjX8yuEDpiOKAUcBJpGEO49GUtMsE26wRCr rjJnEXKCf+oqCIqPGpegh83UlPtHeybMFtb6BbbKkoVSIDCui1/QD1SAqWbFkmiZcx8P S3sV8jO8xtYDaJPCNJ7eapC/YZHusrWShuzACekfZyLouIi441B0P6YB/bNwhMeOvhjf mRbLDrj+Ck3AJUc2B9j/7qcZ4gPrLkKko/SgMc70bHOlYvuLtBec6znbxzV49H5/kLgh bpIah+nbZeLdAwvYyo7uODIeOdMr6yH5kqlSWLfrtvbdzIbgFzgJAYp2heEuaLVlrYUA ti+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GfZZy6f4ONCHbSs2Qu/jlgCAmgGx+8mdb0nvb50XMtI=; b=cbSLZXRNrba9iiTcb+tON5FWnqaeFzD7fVUSjjL3FURynwlgLZ4u1jwasmhpIMMBCE nxxJPlIgK0D7GELgKwOfx1vwUevFY7OdVFN8MG1A+JqpAGBsO+hTdtnnnPMZEgPzYnzo LzNC2ck8uZ92CACkEFY8m84RdsYD3SxshTo9KCb6X9StDtyljKeEIJQXuJx3SbY0Q3J+ XdY+Rw6Hl8+oRy38TO90xybs6K8UOa03sSdth0nifVyy2IMncFg+2XTkc6Ut/OmlXpFn ogI7Wy3I4ZOussYh42AORCrEfCQ5j4zCujJ9+NsnBVOeZ5Etj6n5EtP8IVJT5APPWNNV 8tFw== X-Gm-Message-State: ALQs6tA4SWgPgjiShAaZovi49xU3g02z/Bhe8fgVS4qaAm5Zzk50+aJo 8NVcOoY2fZQy9q4LhggPSnHtGiMl09iXoOk3FLH+hQ== X-Google-Smtp-Source: AIpwx4+IEn5I9MOqs2/6iykcH5J6VIZyPsF6rmoLLrGCza+S67W2JGGB2rLVqiiudJS9RD4bfoYl5F4ejG0ZwJjcs6Y= X-Received: by 2002:a24:b649:: with SMTP id d9-v6mr18992685itj.51.1523026910245; Fri, 06 Apr 2018 08:01:50 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Fri, 6 Apr 2018 08:01:49 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <8935E1F4-10DE-4621-8153-26AF851CC26E@sarenet.es> References: <92b92a3d-3262-c006-ed5a-dc2f9f4a5cb9@zhegan.in> <8935E1F4-10DE-4621-8153-26AF851CC26E@sarenet.es> From: Warner Losh Date: Fri, 6 Apr 2018 09:01:49 -0600 X-Google-Sender-Auth: zlDd8UyAu5DGx72KYqbxjIkpvSo Message-ID: Subject: Re: TRIM, iSCSI and %busy waves To: Borja Marcos Cc: "Eugene M. Zheganin" , FreeBSD-STABLE Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 15:01:54 -0000 On Fri, Apr 6, 2018 at 1:58 AM, Borja Marcos wrote: > > > On 5 Apr 2018, at 17:00, Warner Losh wrote: > > > > I'm working on trim shaping in -current right now. It's focused on NVMe= , > > but since I'm doing the bulk of it in cam_iosched.c, it will eventually > be > > available for ada and da. The notion is to measure how long the TRIMs > take, > > and only send them at 80% of that rate when there's other traffic in th= e > > queue (so if trims are taking 100ms, send them no faster than 8/s). Whi= le > > this will allow for better read/write traffic, it does slow the TRIMs > down > > which slows down whatever they may be blocking in the upper layers. Can= 't > > speak to ZFS much, but for UFS that's freeing of blocks so things like > new > > block allocation may be delayed if we're almost out of disk (which we > have > > no signal for, so there's no way for the lower layers to prioritize tri= ms > > or not). > > Have you considered "hard" shaping including discarding TRIMs when needed= ? > Remember that a TRIM is not a write, which is subject to a contract with > the application, > but a better-if-you-do-it operation. > Well, yes and no. TRIM is there to improve performance, in the long term, of the drives because they'd otherwise get too fragmented and/or have an unacceptably high write amplification. It's more than just a hint, but maybe, in some cases, less than a write. Better if you do it does give some leeway, how much depends on the application. If we were to implement a hard limit on the latency of TRIMs, it would have to be user configurable. There's also the strategy of returning some TRIMs right away, while letting only a percentage through to the device. If I go through with what you're calling hard shaping, I'd also look for ways to allow the upper layers to tell me to hurry up. We have it in the buffer daemon between all the users of bufs when there's a buf shortage, but no similar signal from UFS down to the device to tell it that the results are needed NOW vs needed eventually. And the urgency of the need varies somewhat over time. you could easily send down a boatload of TRIMs with no urgent need for blocks, time passes, and then you have an urgent need for blocks. So you can't add something to the bio going down that it's needed or not since you might not have another TRIM to send down. A new BIO type and/or a tweak to BIO_FLUSH might suffice and be well defined for drivers that don't do weird things. The notion of the upper layers being able to cancel a TRIM that's been queued up was also floated since TRIM + WRITE in quick succession often gives no different performance than just the bare WRITE. And I have no clue what ZFS does wrt TRIMs. So I've considered it, yes. But there's more tricky corners here to consider if it were to be implemented due to (a) the diversity of quality in the market place and (b) the diversity of workloads FreeBSD is used for. > Otherwise, as you say, you might be blocking other operations in the uppe= r > layers. > I am assuming here that with many devices doing TRIMs is better than not > doing them. > And in case of queue congestion doing *some* TRIMs should be better than > doing > no TRIMs at all. > > Yep, not the first time I propose something of the sort, but my queue of > suggestions > to eventually discard TRIMs doesn=E2=80=99s implement the same method ;) > I'm looking at all options, to be honest. I'm not sure what will work the best in the long term. I've observed that, at least with UFS, it's quite easy to survive for hours without finishing the trim with millions of TRIMs in the queue. All it affects are monitoring programs that freak out when you have this many items in the queue for so long (thinking something must be wrong). Of coarse, we control the monitoring programs, so that's easy to fix. (I discovered this when I was doing 1 IOP for TRIMs when running early, buggy versions of this, btw). The backup causes UFS to be waiting on the blocks, if there is a block shortage. Since most of the time there's not, this didn't cause problems when I tweaked a parameter and drained the TRIMs 8 hours after tons of files were deleted.... Warner From owner-freebsd-stable@freebsd.org Fri Apr 6 15:08:09 2018 Return-Path: Delivered-To: freebsd-stable@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 309F9F8CA72 for ; Fri, 6 Apr 2018 15:08:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AC1E680152 for ; Fri, 6 Apr 2018 15:08:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x236.google.com with SMTP id f6-v6so2380236ita.2 for ; Fri, 06 Apr 2018 08:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=NpDWHozfjRN1EYYFE5FUW7yTWGdX6F9rzVVLfwHegFU=; b=udpWOjVf+Jb7rP8jf2m4p5vESNII/FJqGomoVnFhrnCcG/m/U4KZK9Fcl1rqu9IB+4 gZqf9hl1fuQ3MtepWfLlcXDd6ZpIw8XkonEQyClRsWv9cSocJJcpGvBoAiRJ1stc0lEw XTFw1okuKWTk+Gfmnc+o0bP9wOsBdRJEYMCZ4ugMlmTLH4OrYxxQhcnVbiPSdZ9g4JuN TrgADTyWfX8j7TbUpHAippEy91z8zibalTvbeFpYGYROwQoCuXLwlUliHpsqba3h0uk9 9NlS85+YNwNYp/4et83RGqBXcUS7DCaT3oIisaq5MPPmMMq2HPAU3xlJWLtgXcn6bYis o3aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=NpDWHozfjRN1EYYFE5FUW7yTWGdX6F9rzVVLfwHegFU=; b=e7jtsLP9L38p9wddrJMuHAE8XOxHHxO89h9II/j8lamehfpuk3szUCDGB37GCClVL8 /9YdSh58aMosXlWfJwKgp0I0+OKIaTGOSPL1iCo9kDdi3fkdDMlVNCm3nf5kXl38QB6E KqUeE6py6bsrlg2SyYPiSpXOp6xeS3HdHcwuhkZqD+GIf0fvZnAmm+/Psg1EgQCBRDs1 pLw7eOqAFnPHuQDJwNwhXvHAm00cHeY9NAAgX7FX7H8ivyIgwjgvR9MVyGjqUGCwlJaO N+lpNkWSW1nlpUQWea4y37eaW9qTbh9bqzL9Z/1HG8wo7qEZmroqtWhTSydBqvdLRZmU AqCw== X-Gm-Message-State: AElRT7GQVK6YXdHz1SH00J0dJd7yLzZq0ZYCSPLyWeKFKmRCX/0F2ZYV n7/73sz7C4wGLUOVMSAc03XVYE/A5EG8/J4g1qs1TQ== X-Google-Smtp-Source: AIpwx4/12HGj2+VwIO1jczL+gl8vRImjxwDhtU39uGUywzdPx1r/6hOh1QKQsVZ9MLtMc9Jm/BSpRR7egyyJvFlK5uo= X-Received: by 2002:a24:4286:: with SMTP id i128-v6mr18696994itb.73.1523027287554; Fri, 06 Apr 2018 08:08:07 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Fri, 6 Apr 2018 08:08:06 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <9AC3F9CE-B715-4894-B047-38758ACD913C@sarenet.es> References: <92b92a3d-3262-c006-ed5a-dc2f9f4a5cb9@zhegan.in> <8935E1F4-10DE-4621-8153-26AF851CC26E@sarenet.es> <9AC3F9CE-B715-4894-B047-38758ACD913C@sarenet.es> From: Warner Losh Date: Fri, 6 Apr 2018 09:08:06 -0600 X-Google-Sender-Auth: YAqYLyUc8pY6PVTDsSaE2VbgfbI Message-ID: Subject: Re: TRIM, iSCSI and %busy waves To: Borja Marcos Cc: Steven Hartland , "Eugene M. Zheganin" , FreeBSD-STABLE Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 15:08:09 -0000 On Fri, Apr 6, 2018 at 2:56 AM, Borja Marcos wrote: > > > On 6 Apr 2018, at 10:41, Steven Hartland wrote: > > That is very hw and use case dependent. > > The reason we originally sponsored the project to add TRIM to ZFS was tha= t > in our case without TRIM the performance got so bad that we had to secure > erase disks every couple of weeks as they simply became so slow they wher= e > unusable. > > Now admittedly that was a fair few years ago and hw has moved on since > then, but the point remains that it=E2=80=99s not totally true that just = not > TRIMing is an option. > > > As far as I know, letting the device know that you have released a block > should be a Good Thing. > So I prefer to TRIM. I have also seen cases where not doing TRIMs resulte= d > in a terrible performance > although modern SSDs should have better algorithms to deal with it. > > But I have also seen bad cases of TRIM requests piling up and clogging th= e > queues for long periods > of time. Admittedly it was a purely synthetic situation (running bonnie++= ) > but, again, performing > operations like destroying a huge snapshot or dataset could trigger a > similar condition. It was > especially nasty when I tried NVMEs. I mentioned this here: > > https://lists.freebsd.org/pipermail/freebsd-fs/2016-May/023134.html > > > That=E2=80=99s why I think there is a mid point between the radical appro= ach of > not doing TRIMs at all > and clogging the queues with too many of them. > nvd is especially troublesome. It doesn't do any trim shaping *AT*ALL* and we machine gun a huge number of TRIM requests when we delete large files. TRIM is normally not a fast path operation inside the drives, so sending lots of TRIMs down will often starve read/write resources for a variety of reasons (it often forces single threading limiting the parallelism in the drive, it often kicks off GC which causes lots of block erases which are slow and block reads/writes to other pages/blocks on the die (some or all mitigated by planes, but still), etc. > If the TRIM queue gets very large and the =E2=80=9Cmandatory=E2=80=9D ope= rations (read, > writes, etc) begin to > get large delays I think it=E2=80=99s safe to assume that *there is* a pr= oblem and > discarding at least part > of those TRIMs could help to solve it. > That's often a property of the devices, however. And how quickly we shove TRIMs down its throat. I've seen situations where we play out the TRIMs slowly enough that we can see huge latencies in TRIMs (seconds to minutes), but see little to no effect effect on read latency, even in the P99 number since that's often where effects in TRIMs show up and are easiest to measure. Warner > A =E2=80=9CTRIM when you can=E2=80=9D should still be better than a =E2= =80=9CDon=E2=80=99t TRIM at all=E2=80=9D. > > Cheers, > > > > > > Borja. > > P.S: Attaching the graphs that were lost. > > > > > > From owner-freebsd-stable@freebsd.org Fri Apr 6 15:12:55 2018 Return-Path: Delivered-To: freebsd-stable@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 E4349F8D1A1 for ; Fri, 6 Apr 2018 15:12:54 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A627808FD for ; Fri, 6 Apr 2018 15:12:53 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w36FCenl047583 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 6 Apr 2018 17:12:41 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTP id w36FCaWS028998 for ; Fri, 6 Apr 2018 22:12:36 +0700 (+07) (envelope-from eugen@grosbein.net) To: FreeBSD Stable From: Eugene Grosbein Subject: libmap non-absolute paths broken in 11.1-STABLE Message-ID: <5AC78E64.1030308@grosbein.net> Date: Fri, 6 Apr 2018 22:12:36 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE, T_DATE_IN_FUTURE_96_Q autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * 0.0 T_DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: * date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-Spam-Level: ** X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 15:12:55 -0000 Hi! I've just updated my desktop from early 11.1-STABLE to recent one 11.1-STABLE and found that non-absolute paths do not work anymore, like this: libevent-2.0.so.5 compat/pkg/libevent-2.0.so.5.1.10 With luck, this still works: libevent-2.0.so.5 /usr/local/lib/compat/pkg/libevent-2.0.so.5.1.10 Is this known problem? From owner-freebsd-stable@freebsd.org Fri Apr 6 16:49:12 2018 Return-Path: Delivered-To: freebsd-stable@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 5D567F94F75 for ; Fri, 6 Apr 2018 16:49:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EAB1A87B73 for ; Fri, 6 Apr 2018 16:49:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id A4FABF94F71; Fri, 6 Apr 2018 16:49:11 +0000 (UTC) Delivered-To: stable@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 929DAF94F70 for ; Fri, 6 Apr 2018 16:49:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 262AF87B6E for ; Fri, 6 Apr 2018 16:49:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 694CB2154C for ; Fri, 6 Apr 2018 16:49:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w36GnAXv044206 for ; Fri, 6 Apr 2018 16:49:10 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w36GnAOc044205 for stable@FreeBSD.org; Fri, 6 Apr 2018 16:49:10 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 227322] [patch] [iicbus] sys/modules/i2c/iicbus cannot be built outside of kernel build environment Date: Fri, 06 Apr 2018 16:49:10 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: easy, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ian@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 16:49:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227322 --- Comment #1 from commit-hook@freebsd.org --- A commit references this bug: Author: ian Date: Fri Apr 6 16:48:08 UTC 2018 New revision: 332113 URL: https://svnweb.freebsd.org/changeset/base/332113 Log: MFC r331868: Add opt_platform.h for several modules that have #ifdef FDT in the source. Submitted by: Andre Albsmeier PR: 227322 227323 Changes: stable/11/sys/modules/i2c/iicbus/Makefile stable/11/sys/modules/i2c/isl/Makefile stable/11/sys/modules/spi/at45d/Makefile stable/11/sys/modules/spi/mx25l/Makefile stable/11/sys/modules/spi/spibus/Makefile --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Fri Apr 6 16:49:14 2018 Return-Path: Delivered-To: freebsd-stable@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 87C98F94F88 for ; Fri, 6 Apr 2018 16:49:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 22EDC87B82 for ; Fri, 6 Apr 2018 16:49:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id D8485F94F7B; Fri, 6 Apr 2018 16:49:13 +0000 (UTC) Delivered-To: stable@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 C71CDF94F7A for ; Fri, 6 Apr 2018 16:49:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 64CBA87B7A for ; Fri, 6 Apr 2018 16:49:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id A3DF821550 for ; Fri, 6 Apr 2018 16:49:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w36GnCkM044232 for ; Fri, 6 Apr 2018 16:49:12 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w36GnCsL044231 for stable@FreeBSD.org; Fri, 6 Apr 2018 16:49:12 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 227323] [patch] [spi] sys/modules/spi/mx25l cannot be built outside of kernel build environment Date: Fri, 06 Apr 2018 16:49:12 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: easy, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: loos@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 16:49:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227323 --- Comment #1 from commit-hook@freebsd.org --- A commit references this bug: Author: ian Date: Fri Apr 6 16:48:08 UTC 2018 New revision: 332113 URL: https://svnweb.freebsd.org/changeset/base/332113 Log: MFC r331868: Add opt_platform.h for several modules that have #ifdef FDT in the source. Submitted by: Andre Albsmeier PR: 227322 227323 Changes: stable/11/sys/modules/i2c/iicbus/Makefile stable/11/sys/modules/i2c/isl/Makefile stable/11/sys/modules/spi/at45d/Makefile stable/11/sys/modules/spi/mx25l/Makefile stable/11/sys/modules/spi/spibus/Makefile --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Fri Apr 6 16:50:00 2018 Return-Path: Delivered-To: freebsd-stable@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 1C47DF95093 for ; Fri, 6 Apr 2018 16:50:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A9D1687C55 for ; Fri, 6 Apr 2018 16:49:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 6E0DCF95089; Fri, 6 Apr 2018 16:49:59 +0000 (UTC) Delivered-To: stable@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 5CA44F95088 for ; Fri, 6 Apr 2018 16:49:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F0C5887C52 for ; Fri, 6 Apr 2018 16:49:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 3DC4121554 for ; Fri, 6 Apr 2018 16:49:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w36Gnw6b045257 for ; Fri, 6 Apr 2018 16:49:58 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w36GnwkZ045256 for stable@FreeBSD.org; Fri, 6 Apr 2018 16:49:58 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 227322] [patch] [iicbus] sys/modules/i2c/iicbus cannot be built outside of kernel build environment Date: Fri, 06 Apr 2018 16:49:58 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: easy, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ian@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ian@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 16:50:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227322 Ian Lepore changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|New |Closed --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Fri Apr 6 16:50:24 2018 Return-Path: Delivered-To: freebsd-stable@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 AA8EFF95161 for ; Fri, 6 Apr 2018 16:50:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4228D87CDF for ; Fri, 6 Apr 2018 16:50:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 03425F9515F; Fri, 6 Apr 2018 16:50:24 +0000 (UTC) Delivered-To: stable@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 E394AF9515D for ; Fri, 6 Apr 2018 16:50:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7BA5D87CD9 for ; Fri, 6 Apr 2018 16:50:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id BF3EE2155C for ; Fri, 6 Apr 2018 16:50:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w36GoMWU045954 for ; Fri, 6 Apr 2018 16:50:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w36GoMuE045953 for stable@FreeBSD.org; Fri, 6 Apr 2018 16:50:22 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 227323] [patch] [spi] sys/modules/spi/mx25l cannot be built outside of kernel build environment Date: Fri, 06 Apr 2018 16:50:22 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: easy, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ian@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: loos@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 16:50:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227323 Ian Lepore changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|New |Closed --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Fri Apr 6 16:55:26 2018 Return-Path: Delivered-To: freebsd-stable@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 4C15EF9593F for ; Fri, 6 Apr 2018 16:55:26 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id BA88968456 for ; Fri, 6 Apr 2018 16:55:25 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 74CBCF9593C; Fri, 6 Apr 2018 16:55:25 +0000 (UTC) Delivered-To: stable@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 6251CF9593B for ; Fri, 6 Apr 2018 16:55:25 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E0AA76844B for ; Fri, 6 Apr 2018 16:55:24 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 4d74b931-39bb-11e8-91c6-33ffc249f3e8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 4d74b931-39bb-11e8-91c6-33ffc249f3e8; Fri, 06 Apr 2018 16:55:26 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w36GtJuG090750; Fri, 6 Apr 2018 10:55:19 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1523033719.40504.3.camel@freebsd.org> Subject: Re: [Bug 227323] [patch] [spi] sys/modules/spi/mx25l cannot be built outside of kernel build environment From: Ian Lepore To: bugzilla-noreply@freebsd.org, stable@FreeBSD.org Date: Fri, 06 Apr 2018 10:55:19 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 16:55:26 -0000 On Fri, 2018-04-06 at 13:09 +0000, bugzilla-noreply@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227323 > >             Bug ID: 227323 >            Summary: [patch] [spi] sys/modules/spi/mx25l cannot be > built >                     outside of kernel build environment >            Product: Base System >            Version: 11.1-STABLE >           Hardware: Any >                 OS: Any >             Status: New >           Keywords: easy, patch-ready >           Severity: Affects Some People >           Priority: --- >          Component: kern >           Assignee: loos@FreeBSD.org >           Reporter: eugen@freebsd.org >                 CC: eadler@FreeBSD.org, ian@FreeBSD.org, >                     stable@FreeBSD.org > > Created attachment 192286 >   --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=192286&acti > on=edit > The fix > > # cd /usr/src/sys/modules/spi/mx25l && make > cc -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE > -nostdinc   > -I. -I/home/src/sys -fno-common  -fno-omit-frame-pointer > -mno-omit-leaf-frame-pointer   -MD  -MF.depend.mx25l.o -MTmx25l.o > -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float  > -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack- > protector -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing- > prototypes > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs > -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error- > tautological-compare > -Wno-error-empty-body -Wno-error-parentheses-equality > -Wno-error-unused-function -Wno-error-pointer-sign > -Wno-error-shift-negative-value -Wno-error-address-of-packed- > member  -mno-aes > -mno-avx  -std=iso9899:1999 -c /home/src/sys/dev/flash/mx25l.c -o > mx25l.o > /home/src/sys/dev/flash/mx25l.c:30:10: fatal error: 'opt_platform.h' > file not > found > #include "opt_platform.h" >          ^~~~~~~~~~~~~~~~ > 1 error generated. > *** Error code 1 > Does anybody know why mailing lists have recently started being spammed with bug reports?  Using the list to point out a bug that's been languishing without attention for a while might be appropriate, but spamming the list with every action on every bug, IMO, is not. -- Ian From owner-freebsd-stable@freebsd.org Fri Apr 6 18:26:50 2018 Return-Path: Delivered-To: freebsd-stable@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 5FFC0F9C6C7 for ; Fri, 6 Apr 2018 18:26:50 +0000 (UTC) (envelope-from marcnarc@gmail.com) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BC45D6D671 for ; Fri, 6 Apr 2018 18:26:49 +0000 (UTC) (envelope-from marcnarc@gmail.com) Received: by mail-qt0-x22a.google.com with SMTP id f8so2102158qtg.12 for ; Fri, 06 Apr 2018 11:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=E8zu9LAY4G0GzkoKKbDA/Q3iHNomg6lA5jWExwVJRe4=; b=ivHuqX+15ofz9tc/HutNqD2+Jrx1KzD90Oldu20LeXwkNRVIiyE1X0fw+q2jXl345H 4xF9KJ8Qheb/Pm+/q35PI/7ReDt1dkV4YmW7bMDuRZjnGeRCDZWcgE37NghRqwiVmj71 G4JVoDZJfqvY674Gyc5X/Zfftkf3QGVzI2YPJjb77Sk3xkLAiODFx1MXFpRcMZyYWZXh 35QrPL1WLx+M99Eghe32VFGq7sl8hfyJNyNdGU232+LyBZN7jsrrJVG91vVxsd8pf5c1 9WMgXqO1bEZsRFEbfUbIrGcUSAKVtCgr9UmR7/w81x3tCTjChvifTWkjLIjFPHVuIWjQ 4p9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=E8zu9LAY4G0GzkoKKbDA/Q3iHNomg6lA5jWExwVJRe4=; b=P5Z0ZbfEBVNa66dyQwJ9csZZyCXKyg6M8zYWanfXCDf/MySVzcD2e8SnVdQyCm+phO KB4Hb1CXngguUwzEorls/QGp8CVrPmtbzCTjccBehqArMbB6paGDxicgbxCs5gJU6YNU syFOTkGVockwY8czcSF2wuUN+6nsiOuLuDrRIyUp75RoxYslGVXnDrP2aC6NwtnxYzeI DnG9rM+GVsyGtlqyDB0qFCulV19o4gmCcc1JzCbqoqNhTbxX9dDC6e980c9SirVs64zi y7XrVqlvLkh6mUFzt/mVao8vVUwVqFX3OCINTje9/ZSY7CnQMNSeWbrp8jQgxc+pg9i2 0AyA== X-Gm-Message-State: ALQs6tDbr4QAdrgfEOFQ52sOQ79kBJ/Vcac3ynoV81M7PFmJRBmWGSpF KO85IA4SWbvNO/Kui6lgORE= X-Google-Smtp-Source: AIpwx4+EqS7VNZwLedA8vIfy2YvXcFvimwLaBkzXeSeOc1pH2Ci32ksdKDXfhHKpt+zL3a/UPEDDbw== X-Received: by 10.200.65.17 with SMTP id q17mr38224713qtl.122.1523039209069; Fri, 06 Apr 2018 11:26:49 -0700 (PDT) Received: from [10.10.1.32] ([192.252.130.194]) by smtp.gmail.com with ESMTPSA id i188sm8020414qkc.16.2018.04.06.11.26.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Apr 2018 11:26:48 -0700 (PDT) Subject: Re: Problems with ifconfig when starting all jails after 10.3 -> 10.4 upgrade From: Marc Branchaud To: freebsd-stable@FreeBSD.ORG References: <45483fb3-bd94-10f1-a75c-3a035ec69cfa@gmail.com> Message-ID: <94c4e3f3-dac5-2958-3ad4-b4c43e4d21cf@gmail.com> Date: Fri, 6 Apr 2018 14:26:47 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <45483fb3-bd94-10f1-a75c-3a035ec69cfa@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 18:26:50 -0000 On 2018-04-05 10:28 AM, Marc Branchaud wrote: > Hi all, > > I just upgraded from 10.3 to 10.4, and "/etc/rc.d/jail start" is having > problems starting all of my jails: > > # /etc/rc.d/jail start > Starting jails:xipbuild_3_3: created > ifconfig:: bad value > jail: xipbuild_3_3_8: /sbin/ifconfig lo1 inet 10.1.1.38/32 alias: failed > xipbuild_3_4: created > ifconfig:: bad value > jail: xipbuild_4_0: /sbin/ifconfig lo1 inet 10.1.1.5/32 alias: failed > xipbuild: created > xipbuild_4_9: created > ifconfig:: bad value > jail: xipbuild9: /sbin/ifconfig lo1 inet 10.1.1.209/32 alias: failed > . More info: Things work fine with jail_parallel_start="YES". In 10.4, /etc/rc.d/jail now adds "-p1" to the jail command's arguments when starting all jails with jail_parallel_start="NO". It's definitely this parameter that's causing my problems -- changing /etc/rc.d/jail to not add the parameter fixes the problem. M. > This worked fine in 10.3.  I can individually start each jail, e.g. > "/etc/rc.d/jail start xipbuild9". > > All the jails configure the same set of parameters.  Here's my jail.conf: > > --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- > xipbuild_3_3 { >   path="/usr/build-jails/jails/3.3"; >   host.hostname="xipbuild_3_3"; >   ip4.addr="10.1.1.3/32"; > >   allow.chflags; >   allow.mount; >   mount.devfs; > >   persist; > >   mount="/usr/home  /usr/build-jails/jails/3.3/usr/home nullfs rw 0 0"; >   interface="lo1"; > } > xipbuild_3_3_8 { >   path="/usr/build-jails/jails/3.3.8"; >   host.hostname="xipbuild_3_3_8"; >   ip4.addr="10.1.1.38/32"; > >   allow.chflags; >   allow.mount; >   mount.devfs; > >   persist; > >   mount="/usr/home  /usr/build-jails/jails/3.3.8/usr/home nullfs rw 0 0"; >   interface="lo1"; > } > xipbuild_3_4 { >   path="/usr/build-jails/jails/3.4"; >   host.hostname="xipbuild_3_4"; >   ip4.addr="10.1.1.4/32"; > >   allow.chflags; >   allow.mount; >   mount.devfs; > >   persist; > >   mount="/usr/home  /usr/build-jails/jails/3.4/usr/home nullfs rw 0 0"; >   interface="lo1"; > } > xipbuild_4_0 { >   path="/usr/build-jails/jails/4.0"; >   host.hostname="xipbuild_4_0"; >   ip4.addr="10.1.1.5/32"; > >   allow.chflags; >   allow.mount; >   mount.devfs; > >   persist; > >   mount="/usr/home  /usr/build-jails/jails/4.0/usr/home nullfs rw 0 0"; >   interface="lo1"; > } > xipbuild { >   path="/usr/build-jails/jails/latest"; >   host.hostname="xipbuild"; >   ip4.addr="10.1.1.200/32"; > >   allow.chflags; >   allow.mount; >   mount.devfs; > >   persist; > >   mount="/usr/home  /usr/build-jails/jails/latest/usr/home nullfs rw 0 0"; >   interface="lo1"; > } > xipbuild_4_9 { >   path="/usr/build-jails/jails/4.9"; >   host.hostname="xipbuild_4_9"; >   ip4.addr="10.1.1.90/32"; > >   allow.chflags; >   allow.mount; >   mount.devfs; > >   persist; > >   mount="/usr/home  /usr/build-jails/jails/4.9/usr/home nullfs rw 0 0"; >   interface="lo1"; > } > xipbuild9 { >   path="/usr/build-jails/jails/latest9"; >   host.hostname="xipbuild9"; >   ip4.addr="10.1.1.209/32"; > >   allow.chflags; >   allow.mount; >   mount.devfs; > >   persist; > >   mount="/usr/home  /usr/build-jails/jails/latest9/usr/home nullfs rw 0 > 0"; >   interface="lo1"; > } > --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- > > I use ipnat to give the jails network access.  Here's ipnat.rules: > > --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- > map em0 10.1.1.0/24 -> 0/32 proxy port ftp ftp/tcp > map em0 10.1.1.0/24 -> 0/32 > --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- > > And here's my rc.conf: > > --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- > # Generated by Ansible > > # hostname must be FQDN > hostname="devastator.xiplink.com" > > zfs_enable="False" > > # FIXME: previously auto-created? > ifconfig_lo1="create" > > > ifconfig_em0="DHCP SYNCDHCP" > > network_interfaces="em0" > gateway_enable="YES" > > # Prevent rpc > rpcbind_enable="NO" > > # Prevent sendmail to try to connect to localhost > sendmail_enable="NO" > sendmail_submit_enable="NO" > sendmail_outbound_enable="NO" > sendmail_msp_queue_enable="NO" > > # Bring up sshd, it takes some time and uses some entropy on first startup > sshd_enable="YES" > > netwait_enable="YES" > netwait_ip="10.10.0.35" > netwait_if="em0" > > jenkins_swarm_enable="YES" > jenkins_swarm_opts="-executors 8" > > # --- Build jails --- > build_jails_enable="YES" > jail_enable="YES" > > # Set rules in /etc/ipnat.rules > ipnat_enable="YES" > > # Set interface name for ipnat > network_interfaces="${network_interfaces} lo1" > > # Each jail needs to specify its IP address and mask bits in ipv4_addrs_lo1 > ipv4_addrs_lo1="10.1.1.1/32" > > jail_chflags_allow="yes" > > varmfs="NO" > --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- > > Any insight would be deeply appreciated! > >         M. From owner-freebsd-stable@freebsd.org Sat Apr 7 01:13:35 2018 Return-Path: Delivered-To: freebsd-stable@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 6D097F971A3 for ; Sat, 7 Apr 2018 01:13:35 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AF3D87FE6E for ; Sat, 7 Apr 2018 01:13:34 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.sub.de (8.15.2/8.15.2) with ESMTPS id w371D3kA002718 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 7 Apr 2018 03:13:04 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.15.2/8.15.2/Submit) with UUCP id w371D3jF002717 for freebsd-stable@FreeBSD.ORG; Sat, 7 Apr 2018 03:13:03 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id w370srdE036673 for ; Sat, 7 Apr 2018 02:54:53 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id w370s2Hg036587 for ; Sat, 7 Apr 2018 02:54:03 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id w370s2jh036585 for freebsd-stable@FreeBSD.ORG; Sat, 7 Apr 2018 02:54:02 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: Re: kern.sched.quantum: Creepy, sadistic scheduler Date: Sat, 7 Apr 2018 02:47:56 +0200 Organization: even some more stinky socks Message-ID: References: <9FDC510B-49D0-4722-B695-6CD38CA20D4A@gmail.com> <8cfdb8a3-86a0-17ba-1e41-ff1912a30ee9@m5p.com> <5AC5BA42.1010006@grosbein.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 7 Apr 2018 00:48:10 -0000 (UTC) Injection-Info: oper.dinoex.de; logging-data="35506"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48 In-Reply-To: <5AC5BA42.1010006@grosbein.net> Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.sub.de [194.45.71.2]); Sat, 07 Apr 2018 03:13:05 +0200 (CEST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 01:13:35 -0000 Eugene Grosbein wrote: > I see no reasons to use SHED_ULE for such single core systems and use SCHED_BSD. Nitpicking: it is not a single core system, it's a dual that for now is equipped with only one chip, the other is in the shelf. But seriously, I am currently working myself through the design papers for the SCHED_ULE and the SMP stuff, and I tend to be with You and George, in that I do not really need these features. Nevertheless, I think the system should have proper behaviour *as default*, or otherwise there should be a hint in the docs what to do about. Thats the reason why I raise this issue - if the matter can be fixed, thats great, but if we come to the conclusion that small/single-core/CPU-bound/whatever systems are better off with SCHED_4BSD, then thats perfectly fine as well. Or maybe, that those systems should disable preemption? I currently don't know, but i hope we can figure this out, as the problem is clearly visible. P. From owner-freebsd-stable@freebsd.org Sat Apr 7 06:19:58 2018 Return-Path: Delivered-To: freebsd-stable@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 36ECCF8C332 for ; Sat, 7 Apr 2018 06:19:58 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 97BD786329 for ; Sat, 7 Apr 2018 06:19:57 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from [192.168.243.11] ([192.168.243.11]) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTP id w376JpoZ057256 for ; Sat, 7 Apr 2018 11:19:52 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Subject: Re: TRIM, iSCSI and %busy waves To: freebsd-stable@freebsd.org References: <92b92a3d-3262-c006-ed5a-dc2f9f4a5cb9@zhegan.in> <2daf0677-3feb-6c4c-38d3-ed552f1a3cf0@multiplay.co.uk> From: "Eugene M. Zheganin" Message-ID: Date: Sat, 7 Apr 2018 11:19:06 +0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 06:19:58 -0000 Hi, 05.04.2018 20:15, Eugene M. Zheganin wrote: > >> You can indeed tune things here are the relevant sysctls: >> sysctl -a | grep trim |grep -v kstat >> vfs.zfs.trim.max_interval: 1 >> vfs.zfs.trim.timeout: 30 >> vfs.zfs.trim.txg_delay: 32 >> vfs.zfs.trim.enabled: 1 >> vfs.zfs.vdev.trim_max_pending: 10000 >> vfs.zfs.vdev.trim_max_active: 64 >> vfs.zfs.vdev.trim_min_active: 1 >> vfs.zfs.vdev.trim_on_init: 1 >> > Well, I've already seen these. How do I tune them ? The idea of just > tampering with them and seeing what will happen doesn't look like a > bright one to me. Do I increase or decrease them ? Which ones do I > have to avoid ? > So, about these - are there any best practices to fine-tune them ? How do you tune them (I won't blame anyone for examples) ?  Or are they "just there" and nobody touches them ? Thanks. Eugene. From owner-freebsd-stable@freebsd.org Sat Apr 7 04:30:49 2018 Return-Path: Delivered-To: freebsd-stable@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 99EA7F8320B for ; Sat, 7 Apr 2018 04:30:49 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 66D15813D3 for ; Sat, 7 Apr 2018 04:30:47 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (115-166-20-68.dyn.iinet.net.au [115.166.20.68]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w374Uhcj071975 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 6 Apr 2018 21:30:46 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: kern.sched.quantum: Creepy, sadistic scheduler To: George Mitchell , freebsd-stable@freebsd.org References: <9FDC510B-49D0-4722-B695-6CD38CA20D4A@gmail.com> <8cfdb8a3-86a0-17ba-1e41-ff1912a30ee9@m5p.com> From: Julian Elischer Message-ID: <2d3dfb30-fb34-55e4-0572-df17ceb5f66e@freebsd.org> Date: Sat, 7 Apr 2018 12:30:37 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <8cfdb8a3-86a0-17ba-1e41-ff1912a30ee9@m5p.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 04:30:49 -0000 On 4/4/18 9:32 pm, George Mitchell wrote: > On 04/04/18 06:39, Alban Hertroys wrote: >> [...] >> That said, SCHED_ULE (the default scheduler for quite a while now) was designed with multi-CPU configurations in mind and there are claims that SCHED_4BSD works better for single-CPU configurations. You may give that a try, if you're not already on SCHED_4BSD. >> [...] > A small, disgruntled community of FreeBSD users who have never seen > proof that SCHED_ULE is better than SCHED_4BSD in any environment > continue to regularly recompile with SCHED_4BSD. I dread the day when > that becomes impossible, but at least it isn't here yet. -- George > for a single CPU you really should compile a kernel with SMP turned off and 4BSD scheduler. ULE is just trying too hard to do stuff you don't need. From owner-freebsd-stable@freebsd.org Sat Apr 7 12:40:07 2018 Return-Path: Delivered-To: freebsd-stable@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 A6E87F85E0B for ; Sat, 7 Apr 2018 12:40:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 33C7083ED7 for ; Sat, 7 Apr 2018 12:40:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id E7FAFF85E0A; Sat, 7 Apr 2018 12:40:06 +0000 (UTC) Delivered-To: stable@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 D5F77F85E08 for ; Sat, 7 Apr 2018 12:40:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 708A483EBA for ; Sat, 7 Apr 2018 12:40:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 94FAB3D1A for ; Sat, 7 Apr 2018 12:40:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w37Ce5kO039840 for ; Sat, 7 Apr 2018 12:40:05 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w37Ce5tC039834 for stable@FreeBSD.org; Sat, 7 Apr 2018 12:40:05 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 227342] [dpv] dpv -x is broken Date: Sat, 07 Apr 2018 12:40:05 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: dteske@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 12:40:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227342 Bug ID: 227342 Summary: [dpv] dpv -x is broken Product: Base System Version: 11.1-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: dteske@FreeBSD.org Reporter: eugen@freebsd.org CC: stable@FreeBSD.org An example from dpv(1) manual page does not work: tar cf - . | dpv -x "gzip -9 > out.tgz" \ $( du -s . | awk '{print $1 * 1024}' ):label In fact, even simplier command cannot work: dd if=3D/dev/zero bs=3D10000 co= unt=3D1 | dpv -x "cat >/dev/null" 10000:label It just draws initial dialog then sits doing nothing. The reason is that dpv(3) library uses posix_spawn_file_actions_adddup2() function that effectively clobbers standard input file handle with a call to dup2(terminal, 0) and ktrace(1) assures that. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Sat Apr 7 15:13:43 2018 Return-Path: Delivered-To: freebsd-stable@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 BE811F90004 for ; Sat, 7 Apr 2018 15:13:42 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 237EE79361 for ; Sat, 7 Apr 2018 15:13:42 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.sub.de (8.15.2/8.15.2) with ESMTPS id w37FD9AG066504 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 7 Apr 2018 17:13:10 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.15.2/8.15.2/Submit) with UUCP id w37FD9Z2066503 for freebsd-stable@FreeBSD.ORG; Sat, 7 Apr 2018 17:13:09 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id w37EPYNe033364 for ; Sat, 7 Apr 2018 16:25:34 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id w37EOZlu033113 for ; Sat, 7 Apr 2018 16:24:35 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id w37EOZEK033094 for freebsd-stable@FreeBSD.ORG; Sat, 7 Apr 2018 16:24:35 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: more data: SCHED_ULE+PREEMPTION is the problem (was: kern.sched.quantum: Creepy, sadistic scheduler Date: Sat, 7 Apr 2018 16:18:15 +0200 Organization: even some more stinky socks Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 7 Apr 2018 14:19:13 -0000 (UTC) Injection-Info: oper.dinoex.de; logging-data="32143"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48 In-Reply-To: Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.sub.de [194.45.71.2]); Sat, 07 Apr 2018 17:13:11 +0200 (CEST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 15:13:43 -0000 Hi all, in the meantime I did some tests and found the following: A. The Problem: --------------- On a single CPU, there are -exactly- two processes runnable: One is doing mostly compute without I/O - this can be a compressing job or similar; in the tests I used simply an endless-loop. Lets call this the "piglet". The other is doing frequent file reads, but also some compute interim - this can be a backup job traversing the FS, or a postgres VACUUM, or some fast compressor like lz4. Lets call this the "worker". It then happens that the piglet gets 99% CPU, while the worker gets only 0.5% CPU and makes nearly no progress at all. Investigations shows that the worker makes precisely one I/O per timeslice (timeslice as defined in kern.sched.quantum) - or two I/O on a mirrored ZFS. B. Findings: ------------ 1. Filesystem I could never reproduce this when reading from plain UFS. Only when reading from ZFS (direct or via l2arc). 2. Machine The problem originally appeared on a pentium3@1GHz. I was able to reproduce it on an i5-3570T, given the following measures: * config in BIOS to use only one CPU * reduce speed: "dev.cpu.0.freq=200" I did see the problem also when running full speed (which means it happens there also), but could not reproduce it well. 3. kern.sched.preempt_thresh I could make the problem disappear by changing kern.sched.preempt_thresh from the default 80 to either 11 (i5-3570T) or 7 (p3) or smaller. This seems to correspond to the disk interrupt threads, which run at intr:12 (i5-3570T) or intr:8 (p3). 4. dynamic behaviour Here the piglet is already running as PID=2119. Then we can watch the dynamic behaviour as follows (on i5-3570T@200MHz): a. with kern.sched.preempt_thresh=80 $ lz4 DATABASE_TEST_FILE /dev/null & while true; do ps -o pid,pri,"%cpu",command -p 2119,$! sleep 3 done [1] 6073 PID PRI %CPU COMMAND 6073 20 0.0 lz4 DATABASE_TEST_FILE /dev/null 2119 100 91.0 -bash (bash) PID PRI %CPU COMMAND 6073 76 15.0 lz4 DATABASE_TEST_FILE /dev/null 2119 95 74.5 -bash (bash) PID PRI %CPU COMMAND 6073 52 19.0 lz4 DATABASE_TEST_FILE /dev/null 2119 94 71.5 -bash (bash) PID PRI %CPU COMMAND 6073 52 16.0 lz4 DATABASE_TEST_FILE /dev/null 2119 95 76.5 -bash (bash) PID PRI %CPU COMMAND 6073 52 14.0 lz4 DATABASE_TEST_FILE /dev/null 2119 96 80.0 -bash (bash) PID PRI %CPU COMMAND 6073 52 12.5 lz4 DATABASE_TEST_FILE /dev/null 2119 96 82.5 -bash (bash) PID PRI %CPU COMMAND 6073 74 10.0 lz4 DATABASE_TEST_FILE /dev/null 2119 98 86.5 -bash (bash) PID PRI %CPU COMMAND 6073 52 8.0 lz4 DATABASE_TEST_FILE /dev/null 2119 98 89.0 -bash (bash) PID PRI %CPU COMMAND 6073 52 7.0 lz4 DATABASE_TEST_FILE /dev/null 2119 98 90.5 -bash (bash) PID PRI %CPU COMMAND 6073 52 6.5 lz4 DATABASE_TEST_FILE /dev/null 2119 99 91.5 -bash (bash) b. with kern.sched.preempt_thresh=11 PID PRI %CPU COMMAND 4920 21 0.0 lz4 DATABASE_TEST_FILE /dev/null 2119 101 93.5 -bash (bash) PID PRI %CPU COMMAND 4920 78 20.0 lz4 DATABASE_TEST_FILE /dev/null 2119 94 70.5 -bash (bash) PID PRI %CPU COMMAND 4920 82 34.5 lz4 DATABASE_TEST_FILE /dev/null 2119 88 54.0 -bash (bash) PID PRI %CPU COMMAND 4920 85 42.5 lz4 DATABASE_TEST_FILE /dev/null 2119 86 45.0 -bash (bash) PID PRI %CPU COMMAND 4920 85 43.5 lz4 DATABASE_TEST_FILE /dev/null 2119 86 44.5 -bash (bash) PID PRI %CPU COMMAND 4920 85 43.0 lz4 DATABASE_TEST_FILE /dev/null 2119 85 45.0 -bash (bash) PID PRI %CPU COMMAND 4920 85 43.0 lz4 DATABASE_TEST_FILE /dev/null 2119 85 45.5 -bash (bash) From this we can see that in case b. both processes balance out nicely and meet at equal CPU shares. Whereas in case a., after about 10 Seconds (the first 3 records) they move to opposite ends of the scale and stay there. From this I might suppose that here is some kind of mis-calculation or mis-adjustment of the task priorities happening. P. From owner-freebsd-stable@freebsd.org Sat Apr 7 15:13:42 2018 Return-Path: Delivered-To: freebsd-stable@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 0879BF8FFFC for ; Sat, 7 Apr 2018 15:13:42 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F33179344 for ; Sat, 7 Apr 2018 15:13:41 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.sub.de (8.15.2/8.15.2) with ESMTPS id w37FDBAj066511 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 7 Apr 2018 17:13:11 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.15.2/8.15.2/Submit) with UUCP id w37FDBa9066510 for freebsd-stable@FreeBSD.ORG; Sat, 7 Apr 2018 17:13:11 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id w37Ebct4034900 for ; Sat, 7 Apr 2018 16:37:39 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id w37EYcQX034402 for ; Sat, 7 Apr 2018 16:34:38 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id w37EYcHK034391 for freebsd-stable@FreeBSD.ORG; Sat, 7 Apr 2018 16:34:38 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: Re: kern.sched.quantum: Creepy, sadistic scheduler Date: Sat, 7 Apr 2018 16:21:25 +0200 Organization: even some more stinky socks Message-ID: References: <9FDC510B-49D0-4722-B695-6CD38CA20D4A@gmail.com> <8cfdb8a3-86a0-17ba-1e41-ff1912a30ee9@m5p.com> <2d3dfb30-fb34-55e4-0572-df17ceb5f66e@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: oper.dinoex.de; logging-data="32143"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48 In-Reply-To: <2d3dfb30-fb34-55e4-0572-df17ceb5f66e@freebsd.org> Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.sub.de [194.45.71.2]); Sat, 07 Apr 2018 17:13:12 +0200 (CEST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 15:13:42 -0000 Julian Elischer wrote: > for a single CPU you really should compile a kernel with SMP turned off > and 4BSD scheduler. > > ULE is just trying too hard to do stuff you don't need. Julian, if we agree on this, I am fine. (This implies that SCHED_4BSD will *not* be retired for an indefinite time!) I tested yesterday, and SCHED_4BSD doesn't show the annoying behaviour. SMP seems to be no problem (and I need that), but PREEMPTION is definitely related to the problem (see my other message sent now). P.