Re: "Oddness" in head since around r343678 or so

2019-02-12 Thread Niclas Zeising

On 2/12/19 1:38 PM, David Wolfskill wrote:

On Thu, Feb 07, 2019 at 05:09:40AM -0800, David Wolfskill wrote:

...
The laptop is configured to run xdm; while running stable/11 or
stable/12, there's a period of about 5 seconds after xdm's login banner
shows up before either the mouse or keyboard responds.

Up to a few days ago, head was the same, but as of about last weekend (I
think), that period is about 40 seconds while running head.



I no longer observe the above-described delay in head, as of r343998.



Most likely because the coverage stuff were removed from GENERIC.
Regards
--
Nicals
___
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: "Oddness" in head since around r343678 or so

2019-02-12 Thread David Wolfskill
On Thu, Feb 07, 2019 at 05:09:40AM -0800, David Wolfskill wrote:
> ...
> The laptop is configured to run xdm; while running stable/11 or
> stable/12, there's a period of about 5 seconds after xdm's login banner
> shows up before either the mouse or keyboard responds.
> 
> Up to a few days ago, head was the same, but as of about last weekend (I
> think), that period is about 40 seconds while running head.
> 

I no longer observe the above-described delay in head, as of r343998.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Westboro Baptist "Church" appears to delight in taking the name of God in vain.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature


Re: "Oddness" in head since around r343678 or so

2019-02-10 Thread Niclas Zeising

On 2019-02-10 16:35, Niclas Zeising wrote:

On 2019-02-08 10:27, Alexander Leidinger wrote:

Hi,

I recently noticed some generic slowness myself. I experienced this 
during replacing disks in a raidz by bigger ones. Long story short, 
check top -s if you have vnlru running for a long period at high 
CPU... If yes increase kern.maxvnodes (I increased to 10 times). Note, 
we should improve the admin page in the FAQ, the vnlru entry could 
need a little bit more hints and explanations.


If you encounter the same issue we have probably introduced a change 
somewhere with an unintended side effect.


Bye,
Alexander.



Hi!
I'm seeing this as well, on 13-CURRENT.  I updated a computer from the 
last January snapshot (30 or 31 of January, I can't remember) and it 
seems disk IO is very slow.  I remember having a svn checkout taking a 
very long time, with the SVN process pegged at 100% according to top.  I 
can't see the vnlru process running though, but I haven't looked 
closely, and I haven't tried the maxvnodes workaround.  Something has 
changed though.
This is systems using ZFS, both mirror and single disk.  Gstat shows 
disks are mostly idle.


I know this is a lousy bug report, but this, and the feeling that things 
are slower than usual, is what I have for now.

Regards


Hi!
I did some more digging.  In short, disabling options COVERAGE and 
options KCOV made my test case much faster.


My test:
boot system
create a new zfs dataset (zroot/home/test in my case)
time a checkout of https://svn.freebsd.org/base/head, putting the files 
in the new zfs dataset.


This is in no way scientific, since I only ran the test once on each 
kernel, and using something on the network means I'm susceptible to 
varying network speeds and so on, but.
In this specific scenario, using a kernel without those options, it's 
about 3 times faster than with, at least on the computer where I ran the 
tests.


I noticed in the commit log that the coverage and kcov options has been 
disabled again, albeit for a different reason.  Perhaps they should 
remain off, unless the extra runtime overhead can be disabled in 
runtime, similar to witness.

Regards
--
Niclas
___
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: "Oddness" in head since around r343678 or so

2019-02-10 Thread Niclas Zeising

On 2019-02-08 10:27, Alexander Leidinger wrote:

Hi,

I recently noticed some generic slowness myself. I experienced this 
during replacing disks in a raidz by bigger ones. Long story short, 
check top -s if you have vnlru running for a long period at high CPU... 
If yes increase kern.maxvnodes (I increased to 10 times). Note, we 
should improve the admin page in the FAQ, the vnlru entry could need a 
little bit more hints and explanations.


If you encounter the same issue we have probably introduced a change 
somewhere with an unintended side effect.


Bye,
Alexander.



Hi!
I'm seeing this as well, on 13-CURRENT.  I updated a computer from the 
last January snapshot (30 or 31 of January, I can't remember) and it 
seems disk IO is very slow.  I remember having a svn checkout taking a 
very long time, with the SVN process pegged at 100% according to top.  I 
can't see the vnlru process running though, but I haven't looked 
closely, and I haven't tried the maxvnodes workaround.  Something has 
changed though.
This is systems using ZFS, both mirror and single disk.  Gstat shows 
disks are mostly idle.


I know this is a lousy bug report, but this, and the feeling that things 
are slower than usual, is what I have for now.

Regards
--
___
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: "Oddness" in head since around r343678 or so

2019-02-08 Thread Alexander Leidinger

Hi,

I recently noticed some generic slowness myself. I experienced this during 
replacing disks in a raidz by bigger ones. Long story short, check top -s 
if you have vnlru running for a long period at high CPU... If yes increase 
kern.maxvnodes (I increased to 10 times). Note, we should improve the admin 
page in the FAQ, the vnlru entry could need a little bit more hints and 
explanations.


If you encounter the same issue we have probably introduced a change 
somewhere with an unintended side effect.


Bye,
Alexander.

--
Send from a mobile device, please forgive brevity and misspellings.

Am 7. Februar 2019 4:43:43 nachm. schrieb "Rodney W. Grimes" 
:



I run and track stable/11, stable/12, and head (from separate slices --
no VMs involved) on my laptop; among other things, this permits some
degree of comparison among them.

The laptop is configured to run xdm; while running stable/11 or
stable/12, there's a period of about 5 seconds after xdm's login banner
shows up before either the mouse or keyboard responds.

Up to a few days ago, head was the same, but as of about last weekend (I
think), that period is about 40 seconds while running head.

I realize that's a little ... lacking in specificity, and I apologize
for that.  And while I noticed it a few days ago, I hadn't actually
timed it until this morning.


My addition is going to lack even worse, I have been seeing very
long periods of lag, on this 40 second order, when a bhyve instance
is started.  The interactive response for this time is 0, not
even ^t produces any output.  The prompt comes back almost immediatly
after typing the bhyve command, but that prompt is dead for a
very long time.

I am running 12.0-RELEASE, and see this issue on multiple machines.



Information, including verbose dmesg.boot copies and a log of uname
outputs, may be found from the page at
.

Here's a list of the uname outputs for head over the last several days:

FreeBSD 13.0-CURRENT #245 r343551M/343551: Tue Jan 29 03:54:46 PST 2019 
r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
amd64 1300010
FreeBSD 13.0-CURRENT #246 r343572M/343572: Wed Jan 30 05:14:44 PST 2019 
r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
amd64 1300010
FreeBSD 13.0-CURRENT #247 r343604M/343604: Thu Jan 31 03:53:37 PST 2019 
r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
amd64 1300010
FreeBSD 13.0-CURRENT #248 r343646M/343658: Fri Feb  1 04:05:45 PST 2019 
r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
amd64 1300010
FreeBSD 13.0-CURRENT #249 r343678M/343678: Sat Feb  2 03:55:23 PST 2019 
r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
amd64 1300010
FreeBSD 13.0-CURRENT #250 r343707M/343711: Sun Feb  3 04:06:08 PST 2019 
r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
amd64 1300010
FreeBSD 13.0-CURRENT #251 r343732M/343741: Mon Feb  4 04:24:07 PST 2019 
r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
amd64 1300010
FreeBSD 13.0-CURRENT #252 r343770M/343771: Tue Feb  5 04:27:38 PST 2019 
r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
amd64 1300010
FreeBSD 13.0-CURRENT #253 r343828M/343834: Wed Feb  6 03:59:36 PST 2019 
r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
amd64 1300010
FreeBSD 13.0-CURRENT #254 r343867M/343867: Thu Feb  7 04:52:38 PST 2019 
r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
amd64 1300010


Peace,
david
--
David H. Wolfskill  da...@catwhisker.org
"It was like reading a Donald Trump tweet.  It didn't make any sense."

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


--
Rod Grimes rgri...@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"




___
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: "Oddness" in head since around r343678 or so

2019-02-07 Thread Rodney W. Grimes
> I run and track stable/11, stable/12, and head (from separate slices --
> no VMs involved) on my laptop; among other things, this permits some
> degree of comparison among them.
> 
> The laptop is configured to run xdm; while running stable/11 or
> stable/12, there's a period of about 5 seconds after xdm's login banner
> shows up before either the mouse or keyboard responds.
> 
> Up to a few days ago, head was the same, but as of about last weekend (I
> think), that period is about 40 seconds while running head.
> 
> I realize that's a little ... lacking in specificity, and I apologize
> for that.  And while I noticed it a few days ago, I hadn't actually
> timed it until this morning.

My addition is going to lack even worse, I have been seeing very
long periods of lag, on this 40 second order, when a bhyve instance
is started.  The interactive response for this time is 0, not
even ^t produces any output.  The prompt comes back almost immediatly
after typing the bhyve command, but that prompt is dead for a
very long time.

I am running 12.0-RELEASE, and see this issue on multiple machines.

> 
> Information, including verbose dmesg.boot copies and a log of uname
> outputs, may be found from the page at
> .
> 
> Here's a list of the uname outputs for head over the last several days:
> 
> FreeBSD 13.0-CURRENT #245 r343551M/343551: Tue Jan 29 03:54:46 PST 2019 
> r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300010
> FreeBSD 13.0-CURRENT #246 r343572M/343572: Wed Jan 30 05:14:44 PST 2019 
> r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300010
> FreeBSD 13.0-CURRENT #247 r343604M/343604: Thu Jan 31 03:53:37 PST 2019 
> r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300010
> FreeBSD 13.0-CURRENT #248 r343646M/343658: Fri Feb  1 04:05:45 PST 2019 
> r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300010
> FreeBSD 13.0-CURRENT #249 r343678M/343678: Sat Feb  2 03:55:23 PST 2019 
> r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300010
> FreeBSD 13.0-CURRENT #250 r343707M/343711: Sun Feb  3 04:06:08 PST 2019 
> r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300010
> FreeBSD 13.0-CURRENT #251 r343732M/343741: Mon Feb  4 04:24:07 PST 2019 
> r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300010
> FreeBSD 13.0-CURRENT #252 r343770M/343771: Tue Feb  5 04:27:38 PST 2019 
> r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300010
> FreeBSD 13.0-CURRENT #253 r343828M/343834: Wed Feb  6 03:59:36 PST 2019 
> r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300010
> FreeBSD 13.0-CURRENT #254 r343867M/343867: Thu Feb  7 04:52:38 PST 2019 
> r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300010
> 
> Peace,
> david
> -- 
> David H. Wolfskillda...@catwhisker.org
> "It was like reading a Donald Trump tweet.  It didn't make any sense."
> 
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.

-- 
Rod Grimes rgri...@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"


"Oddness" in head since around r343678 or so

2019-02-07 Thread David Wolfskill
I run and track stable/11, stable/12, and head (from separate slices --
no VMs involved) on my laptop; among other things, this permits some
degree of comparison among them.

The laptop is configured to run xdm; while running stable/11 or
stable/12, there's a period of about 5 seconds after xdm's login banner
shows up before either the mouse or keyboard responds.

Up to a few days ago, head was the same, but as of about last weekend (I
think), that period is about 40 seconds while running head.

I realize that's a little ... lacking in specificity, and I apologize
for that.  And while I noticed it a few days ago, I hadn't actually
timed it until this morning.

Information, including verbose dmesg.boot copies and a log of uname
outputs, may be found from the page at
.

Here's a list of the uname outputs for head over the last several days:

FreeBSD 13.0-CURRENT #245 r343551M/343551: Tue Jan 29 03:54:46 PST 2019 
r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1300010
FreeBSD 13.0-CURRENT #246 r343572M/343572: Wed Jan 30 05:14:44 PST 2019 
r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1300010
FreeBSD 13.0-CURRENT #247 r343604M/343604: Thu Jan 31 03:53:37 PST 2019 
r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1300010
FreeBSD 13.0-CURRENT #248 r343646M/343658: Fri Feb  1 04:05:45 PST 2019 
r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1300010
FreeBSD 13.0-CURRENT #249 r343678M/343678: Sat Feb  2 03:55:23 PST 2019 
r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1300010
FreeBSD 13.0-CURRENT #250 r343707M/343711: Sun Feb  3 04:06:08 PST 2019 
r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1300010
FreeBSD 13.0-CURRENT #251 r343732M/343741: Mon Feb  4 04:24:07 PST 2019 
r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1300010
FreeBSD 13.0-CURRENT #252 r343770M/343771: Tue Feb  5 04:27:38 PST 2019 
r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1300010
FreeBSD 13.0-CURRENT #253 r343828M/343834: Wed Feb  6 03:59:36 PST 2019 
r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1300010
FreeBSD 13.0-CURRENT #254 r343867M/343867: Thu Feb  7 04:52:38 PST 2019 
r...@g1-49.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1300010

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"It was like reading a Donald Trump tweet.  It didn't make any sense."

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature