Re: freebsd 13 ryzen micro stutter

[monochrome]

OP here, I've been running with kern.sched.steal_thresh=1 with no 
stutter since it was originally suggested. I tried these instead and I 
get stutter, maybe a little less but its definitely back.



On 4/3/21 1:23 AM, Rozhuk Ivan wrote:

I have no micro stutter with default kern.sched.steal_thresh=2, but I have set:
kern.sched.balance=0# Enables the long-term load balancer
kern.sched.balance_interval=1000# Average period in stathz ticks to run 
the long-term balancer
kern.sched.affinity=1   # Number of hz ticks to keep thread 
affinity for

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

Re: freebsd 13 ryzen micro stutter

[Rozhuk Ivan]

On Wed, 31 Mar 2021 02:35:25 -0700
Alastair Hogge  wrote:

> On 2021-03-28 16:09, Hans Petter Selasky wrote:
> > On 3/27/21 11:54 AM, Santiago Martinez wrote:  
> >> Hi, i have the same output as @Nils B. If i run with steal =2 and
> >> dtrace the micro stutter doesn't happen but as soon as i stop the
> >> dtrace script it the stutters come back again. 
> > 
> > Here is a patch which you can try. Not sure if it helps.
> > https://reviews.freebsd.org/D29467  
> 
> Thanks Hans, this reduces jitter somewhat, but it still noticeable in
> Quake2. I left kern.sched.steal_thresh at 1.
> 

I have no micro stutter with default kern.sched.steal_thresh=2, but I have set:
kern.sched.balance=0# Enables the long-term load balancer
kern.sched.balance_interval=1000# Average period in stathz ticks to run 
the long-term balancer
kern.sched.affinity=1   # Number of hz ticks to keep thread 
affinity for
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: system freeze on 14.0-CURRENT

[Masachika ISHIZUKA]

>>   main-8223717ce is working fine on vostro 3267, but isn't
>> working on XPS 12.
> 
>   main-4d221f59b is freezed on vostro 3267.

  Although main-8223717ce wasn't frozen on vostro 3267 yesterday,
main-8223717ce is frozen on vostro 3267 today.
-- 
Masachika ISHIZUKA
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: system freeze on 14.0-CURRENT

[Masachika ISHIZUKA]

>   main-8223717ce is working fine on vostro 3267, but isn't
> working on XPS 12.

  main-4d221f59b is freezed on vostro 3267.
-- 
Masachika ISHIZUKA
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

systat -swap to display large swap space users

[Yoshihiro Ota]

Hi,

We do not seem to have a nice way to see current swap space usage per process.
I updated systat to use libprocstat to obtain such infomation and display
along with swap devise/file stats.

I think patch works for 14-CURRENT and 13-STABLE/13.0-*.
12-STABLE needs some changes from main.

The new screen looks like below with 'systat -swap':


/0   /1   /2   /3   /4   /5   /6   /7   /8   /9   /10
 Load Average   | 

Device/Path   Size  Used |0%  /10  /20  /30  /40  / 60\  70\  80\  90\ 100|
ada0s1b  2048M 2034M X
zvol/sys/tempora 1024M 1015M X
zvol/sys/swap1024M 1014M X
Total4096M 4063M X

PidUsername   Command Swap/Total Per-ProcessPer-System
 24153 hiro   seamonkey   98M /   1G  7%  2%
 23677 hiro   xfce4-pane  28M /  81M 34% XXX  0%
 23629 hiro   xfce4-sess  25M / 118M 21% XX   0%
 23681 hiro   xfdesktop   20M /  58M 34% XXX  0%
 23678 hiro   thunar  15M /  43M 36% XXX  0%
 23658 hiro   at-spi-bus  14M /  23M 63% XX   0%
 23660 hiro   gvfsd   12M /  21M 56% X0%

Disks  ada0  ada1  ada2   cd0 pass0 pass1 pass2 pass3
KB/t   8.00  0.00  0.00  0.00  0.00  0.00  0.00  0.00
tps   0 0 0 0 1 0 0 0
MB/s   0.00  0.00  0.00  0.00  0.00  0.00  0.00  0.00
%busy 0 0 0 0 0 0 0 0

Hiro
diff --git a/usr.bin/systat/Makefile b/usr.bin/systat/Makefile
index ca3f7ed72ce..bfbe1336d29 100644
--- a/usr.bin/systat/Makefile
+++ b/usr.bin/systat/Makefile
@@ -5,7 +5,7 @@
 
 PROG=	systat
 SRCS=	cmds.c cmdtab.c devs.c fetch.c iostat.c keyboard.c main.c sysput.c \
-	netcmds.c netstat.c pigs.c swap.c icmp.c \
+	netcmds.c netstat.c pigs.c proc.c swap.c icmp.c \
 	mode.c ip.c sctp.c tcp.c zarc.c \
 	vmstat.c convtbl.c ifcmds.c ifstat.c
 
@@ -16,6 +16,6 @@ CFLAGS+= -DINET6
 
 WARNS?=	1
 
-LIBADD=	ncursesw m devstat kvm util
+LIBADD=	ncursesw m devstat kvm util procstat
 
 .include 
diff --git a/usr.bin/systat/devs.h b/usr.bin/systat/devs.h
index cbedd844290..79a44a6c3f5 100644
--- a/usr.bin/systat/devs.h
+++ b/usr.bin/systat/devs.h
@@ -34,6 +34,8 @@
 
 #include 
 
+#define DISKHIGHT 5
+
 int dsinit(int);
 void dsgetinfo(struct statinfo *);
 int dscmd(const char *, const char *, int, struct statinfo *);
diff --git a/usr.bin/systat/main.c b/usr.bin/systat/main.c
index b5a19d381ad..b84351379f4 100644
--- a/usr.bin/systat/main.c
+++ b/usr.bin/systat/main.c
@@ -135,6 +135,21 @@ parse_cmd_args (int argc, char **argv)
 
 }
 
+static void
+resize(int signo __unused)
+{
+
+	endwin();
+	refresh();
+	clear();
+
+	CMDLINE = LINES - 1;
+	labels();
+	display();
+	status();
+}
+
+
 int
 main(int argc, char **argv)
 {
@@ -191,6 +206,7 @@ main(int argc, char **argv)
 	signal(SIGINT, die);
 	signal(SIGQUIT, die);
 	signal(SIGTERM, die);
+	signal(SIGWINCH, resize);
 
 	/*
 	 * Initialize display.  Load average appears in a one line
diff --git a/usr.bin/systat/proc.c b/usr.bin/systat/proc.c
new file mode 100644
index 000..0def660d2dc
--- /dev/null
+++ b/usr.bin/systat/proc.c
@@ -0,0 +1,192 @@
+/*-
+ * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
+ *
+ * Copyright (c) 2021 Yoshihiro Ota
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * $FreeBSD$
+ */
+
+#include 
+__FBSDID("$FreeBSD$");
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "subs.h"
+#include "systat.h"
+#include "extern.h"
+
+static int compar(const 

Re: [SOLVED] Re: Strange behavior after running under high load

[Mateusz Guzik]

On 4/2/21, Stefan Esser  wrote:
> Am 28.03.21 um 16:39 schrieb Stefan Esser:
>> After a period of high load, my now idle system needs 4 to 10 seconds to
>> run any trivial command - even after 20 minutes of no load ...
>>
>>
>> I have run some Monte-Carlo simulations for a few hours, with initially
> 35
>> processes running in parallel for some 10 seconds each.
>>
>> The load decreased over time since some parameter sets were faster to
>> process.
>> All in all 63000 processes ran within some 3 hours.
>>
>> When the system became idle, interactive performance was very bad.
>> Running
>> any trivial command (e.g. uptime) takes some 5 to 10 seconds. Since I
>> have
>> to have this system working, I plan to reboot it later today, but will
>> keep
>> it in this state for some more time to see whether this state persists or
>> whether the system recovers from it.
>>
>> Any ideas what might cause such a system state???
>
> Seems that Mateusz Guzik was right to mention performance issues when
> the system is very low on vnodes. (Thanks!)
>
> I have been able to reproduce the issue and have checked vnode stats:
>
> kern.maxvnodes: 620370
> kern.minvnodes: 155092
> vm.stats.vm.v_vnodepgsout: 6890171
> vm.stats.vm.v_vnodepgsin: 18475530
> vm.stats.vm.v_vnodeout: 228516
> vm.stats.vm.v_vnodein: 1592444
> vfs.wantfreevnodes: 155092
> vfs.freevnodes: 47<- obviously too low ...
> vfs.vnodes_created: 19554702
> vfs.numvnodes: 621284
> vfs.cache.debug.vnodes_cel_3_failures: 0
> vfs.cache.stats.heldvnodes: 6412
>
> The freevnodes value stayed in this region over several minutes, with
> typical program start times (e.g. for "uptime") in the region of 10 to
> 15 seconds.
>
> After rising maxvnodes to 2,000,000 form 600,000 the system performance
> is restored and I get:
>
> kern.maxvnodes: 200
> kern.minvnodes: 50
> vm.stats.vm.v_vnodepgsout: 7875198
> vm.stats.vm.v_vnodepgsin: 20788679
> vm.stats.vm.v_vnodeout: 261179
> vm.stats.vm.v_vnodein: 1817599
> vfs.wantfreevnodes: 50
> vfs.freevnodes: 205988<- still a lot higher than wantfreevnodes
> vfs.vnodes_created: 19956502
> vfs.numvnodes: 912880
> vfs.cache.debug.vnodes_cel_3_failures: 0
> vfs.cache.stats.heldvnodes: 20702
>
> I do not know why the performance impact is so high - there are a few
> free vnodes (more than required for the shared libraries to start e.g.
> the uptime program). Most probably each attempt to get a vnode triggers
> a clean-up attempt that runs for a significant time, but has no chance
> to actually reach near the goal of 155k or 500k free vnodes.
>

It is high because of this:
msleep(_sig, _list_mtx, PVFS, "vlruwk", hz);

i.e. it literally sleeps for 1 second.

The vnode limit is probably too conservative and behavior when limit
is reached is rather broken. Probably the thing to do is to let
allocations go through while kicking vnlru to free some stuff up. I'll
have to sleep on it.


> Anyway, kern.maxvnodes can be changed at run-time and it is thus easy
> to fix. It seems that no message is logged to report this situation.
> A rate limited hint to rise the limit should help other affected users.
>
> Regards, STefan
>
>


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

[SOLVED] Re: Strange behavior after running under high load

[Stefan Esser]

Am 28.03.21 um 16:39 schrieb Stefan Esser:

After a period of high load, my now idle system needs 4 to 10 seconds to
run any trivial command - even after 20 minutes of no load ...


I have run some Monte-Carlo simulations for a few hours, with initially 
35 

processes running in parallel for some 10 seconds each.

The load decreased over time since some parameter sets were faster to process.
All in all 63000 processes ran within some 3 hours.

When the system became idle, interactive performance was very bad. Running
any trivial command (e.g. uptime) takes some 5 to 10 seconds. Since I have
to have this system working, I plan to reboot it later today, but will keep
it in this state for some more time to see whether this state persists or
whether the system recovers from it.

Any ideas what might cause such a system state???


Seems that Mateusz Guzik was right to mention performance issues when
the system is very low on vnodes. (Thanks!)

I have been able to reproduce the issue and have checked vnode stats:

kern.maxvnodes: 620370
kern.minvnodes: 155092
vm.stats.vm.v_vnodepgsout: 6890171
vm.stats.vm.v_vnodepgsin: 18475530
vm.stats.vm.v_vnodeout: 228516
vm.stats.vm.v_vnodein: 1592444
vfs.wantfreevnodes: 155092
vfs.freevnodes: 47  <- obviously too low ...
vfs.vnodes_created: 19554702
vfs.numvnodes: 621284
vfs.cache.debug.vnodes_cel_3_failures: 0
vfs.cache.stats.heldvnodes: 6412

The freevnodes value stayed in this region over several minutes, with
typical program start times (e.g. for "uptime") in the region of 10 to
15 seconds.

After rising maxvnodes to 2,000,000 form 600,000 the system performance
is restored and I get:

kern.maxvnodes: 200
kern.minvnodes: 50
vm.stats.vm.v_vnodepgsout: 7875198
vm.stats.vm.v_vnodepgsin: 20788679
vm.stats.vm.v_vnodeout: 261179
vm.stats.vm.v_vnodein: 1817599
vfs.wantfreevnodes: 50
vfs.freevnodes: 205988  <- still a lot higher than wantfreevnodes
vfs.vnodes_created: 19956502
vfs.numvnodes: 912880
vfs.cache.debug.vnodes_cel_3_failures: 0
vfs.cache.stats.heldvnodes: 20702

I do not know why the performance impact is so high - there are a few
free vnodes (more than required for the shared libraries to start e.g.
the uptime program). Most probably each attempt to get a vnode triggers
a clean-up attempt that runs for a significant time, but has no chance
to actually reach near the goal of 155k or 500k free vnodes.

Anyway, kern.maxvnodes can be changed at run-time and it is thus easy
to fix. It seems that no message is logged to report this situation.
A rate limited hint to rise the limit should help other affected users.

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

Re: Scrub incredibly slow with 13.0-RC3 (as well as RC1 & 2)

[Mathieu Chouquet-Stringer]

On Fri, Apr 02, 2021 at 08:29:43PM +, Dave Cottlehuber wrote:
> Does the issue also go away if you use `TSC-slow` ?

I haven't, I can try it out. Yeah TSC-slow is poorly rated (-100) but
scrubbing my zroot is much faster with it compared to ACPI-fast (rated
at 900)..

TSC-slow:
  scan: scrub repaired 0B in 00:00:12 with 0 errors on Fri Apr  2 22:37:06 2021
  scan: scrub repaired 0B in 00:00:09 with 0 errors on Fri Apr  2 22:41:17 2021
  scan: scrub repaired 0B in 00:00:09 with 0 errors on Fri Apr  2 22:41:40 2021

ACPI-fast:
  scan: scrub repaired 0B in 00:03:33 with 0 errors on Fri Apr  2 22:40:47 2021
  scan: scrub repaired 0B in 00:03:29 with 0 errors on Fri Apr  2 22:46:14 2021
  scan: scrub repaired 0B in 00:03:38 with 0 errors on Fri Apr  2 22:49:52 2021

So really ACPI-fast is not appropriately named, at least under KVM. Same
thing as HPET... TSC-slow looks as good as kvmclock based on that simple
benchmark but I guess there's a reason why it's at the bottom of the
pile.

> I investigated exactly this issue yesterday[1],  and it's great to see 
> Bryan's patch
> resurrected, I will try it here and report back too.
> 
> [1]: https://hackmd.io/HhYlbsDJTpCWHSwlrwrY_w

FYI I created a new revision to have that patch merged (and there's a better 
version of
it there):
https://reviews.freebsd.org/D29531

Honestly the kvmclock patch is a game changer but I look forward to
hearing your feedback.

-- 
Mathieu Chouquet-Stringer
The sun itself sees not till heaven clears.
 -- William Shakespeare --
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Correct net80211 channel flag.

[Adrian Chadd]

lemme go see (again). That's why I wanted to re-review it all before I
landed stuff!


-a

On Fri, 2 Apr 2021 at 13:41, Bjoern A. Zeeb
 wrote:
>
> On 2 Apr 2021, at 6:44, Adrian Chadd wrote:
>
> > I've got this in my local tree now.
>
> That’s not a good idea?
>
> > I have a note to go dig up which
> > draft I yanked this from and update it with reference to the draft and
> > the current spec.
> >
> > Thanks for pointing this out!
>
> Aehm, am I missing something but I believe everywhere we use these
> values
> we do properly apply a maskshift apart from
> ieee80211_vht_get_vhtcap_ie() where
> we apply a shiftmask when setting them again after doing the logic
> checks
> so changing them will do us no good at all  or am I looking at the wrong
> tree?
>
> /bz
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Correct net80211 channel flag.

[Bjoern A. Zeeb]

On 2 Apr 2021, at 6:44, Adrian Chadd wrote:


I've got this in my local tree now.


That’s not a good idea?


I have a note to go dig up which
draft I yanked this from and update it with reference to the draft and
the current spec.

Thanks for pointing this out!


Aehm, am I missing something but I believe everywhere we use these 
values
we do properly apply a maskshift apart from 
ieee80211_vht_get_vhtcap_ie() where
we apply a shiftmask when setting them again after doing the logic 
checks
so changing them will do us no good at all  or am I looking at the wrong 
tree?


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

Re: Scrub incredibly slow with 13.0-RC3 (as well as RC1 & 2)

[Dave Cottlehuber]

On Wed, 31 Mar 2021, at 09:00, Mathieu Chouquet-Stringer wrote:
> On Tue, Mar 30, 2021 at 03:43:06PM +0200, Mathieu Chouquet-Stringer wrote:
> > Hello,
> > 
> > TL;DR: we need kvmclock support in FreeBSD
> 
>   scan: scrub repaired 0B in 12:33:11 with 0 errors on Wed Mar 31 03:33:14 
> 2021
> 
> It's almost twice as fast with kvmclock support...

Does the issue also go away if you use `TSC-slow` ?

I investigated exactly this issue yesterday[1],  and it's great to see Bryan's 
patch
resurrected, I will try it here and report back too.

[1]: https://hackmd.io/HhYlbsDJTpCWHSwlrwrY_w

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

Re: NPAPI (was: java web start / error)

[Daniel Nebdal]

On Fri, 2 Apr 2021 at 04:07, Graham Perrin  wrote:
>
> On 05/03/2021 14:01, Antonio Olivares wrote:
> > … worked well with firefox-esr which I use because the plugins
> > are deprecated using the newer firefox.  Despite that it also used to
> > work with the regular firefox. …
>
> For reference – I dug up some of what's below in response to a question
> in IRC about :
>
> Removal of NPAPI plugin support in Firefox 85
> 
>
> Java Plugin is Removed from JDK 8u for Linux, Solaris, and MacOS Platforms
> 
>
>  no recent activity, and
> related  does not respond.
>
>  about Pale Moon.

At this point, it may be easier to get hold of an old OS, an old copy
of Firefox, and an old Java plugin, install them in a virtual machine,
and firewall it so the VM only has access to that one site. Much like
VHS, you apparently need to view it on preserved tech of a similar
vintage. On the positive side, a setup like that should at least keep
working indefinitely, unless they also manage to use HTTPS
certificates an old browser can't understand.

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

Re: Missing sysctl OID in RC4

[Athan Papadimitriou]

I did not know that SCTP has been removed from the GENERIC kernel.

Thank you all

On Thu, Apr 1, 2021 at 2:41 PM  wrote:
>
> > -Original Message-
> > From: owner-freebsd-curr...@freebsd.org  > curr...@freebsd.org> On Behalf Of Athan Papadimitriou
> > Sent: Thursday, 1 April 2021 08:15
> > To: freebsd-current@freebsd.org
> > Subject: Missing sysctl OID in RC4
> >
> > Do you know if net.inet.sctp.blackhole has been removed from r13?
> > Sysctl says it is unknown though still described in blackhole(4)
>
> SCTP is not included in the GENERIC kernel anymore.
> So the sysctl is only available when the sctp.ko kernel module is loaded.
>
>
> > Thanks
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Correct net80211 channel flag.

[Adrian Chadd]

I've got this in my local tree now. I have a note to go dig up which
draft I yanked this from and update it with reference to the draft and
the current spec.

Thanks for pointing this out!


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