Re: kern.sched.quantum: Creepy, sadistic scheduler

[Eugene Grosbein]

19.04.2018 0:59, Peter wrote:

>   thank You very much for Your commenting and reports!
> 
> From what I see, we have (at least) two rather different demands here:
> while George looks at the over-all speed of compute throughput, others are 
> concerned about interactive response.
> 
> My own issue is again a little bit different: I am running this small 
> single-CPU machine as my home-office router, and it also runs a backup 
> service, which involves compressing big files and handling an outgrown 
> database (but that does not need to happen fast, as it's just backup stuff).
> So, my demand is to maintain a good balance between realtime network activity 
> being immediately served, and low-priority batch compute jobs, while still 
> staying responsive to shell-commands - but the over-all compute throughput is 
> not important here.
> 
> But then, I find it very difficult to devise some metrics, by which such a 
> demand could be properly measured, to get compareable figures.

I run similar system (AMD Geode 500Mhz i386-compatible) and found that
SCHED_4BSD does it just fine without any additional non-default configuration:
no other kernel options (*PREEMPT*), no loader.conf/sysctl.conf tuning.


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

[Bug 227603] [panic] r323477: Sleeping thread owns a non-sleepable lock

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227603

Eugene Grosbein  changed:

   What|Removed |Added

 Status|New |In Progress
   See Also||https://reviews.freebsd.org
   ||/D14982

--- Comment #3 from Eugene Grosbein  ---
(In reply to Stephen Hurd from comment #2)

I've applied the fix from https://reviews.freebsd.org/D14982.
While shutting old kernel down to reboot with new kernel, it paniced again with
the same backtrace.

Now I run the system with the fix and will respond if something bad happens or
in a week in case of normal work.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 227603] [panic] r323477: Sleeping thread owns a non-sleepable lock

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227603

Stephen Hurd  changed:

   What|Removed |Added

   Assignee|mjo...@freebsd.org  |sh...@freebsd.org
 CC||sh...@freebsd.org

--- Comment #2 from Stephen Hurd  ---
Can you test with r332734 and ensure the issue is resolved?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: kern.sched.quantum: Creepy, sadistic scheduler

[Peter]

Hi all of You,

  thank You very much for Your commenting and reports!

From what I see, we have (at least) two rather different demands here: 
while George looks at the over-all speed of compute throughput, others 
are concerned about interactive response.


My own issue is again a little bit different: I am running this small 
single-CPU machine as my home-office router, and it also runs a backup 
service, which involves compressing big files and handling an outgrown 
database (but that does not need to happen fast, as it's just backup stuff).
So, my demand is to maintain a good balance between realtime network 
activity being immediately served, and low-priority batch compute jobs, 
while still staying responsive to shell-commands - but the over-all 
compute throughput is not important here.


But then, I find it very difficult to devise some metrics, by which such 
a demand could be properly measured, to get compareable figures.



George Mitchell wrote:

I suspect my case (make buildworld while running misc/dnetc) doesn't
qualify.  However, I just completed a SCHED_ULE run with
preempt_thresh set to 5, and "time make buildworld" reports:
7336.748u 677.085s 9:25:19.86 23.6% 27482+473k 42147+431581io 38010pf+0w
Much closer to SCHED_4BSD!  I'll try preempt_thresh=0 next, and I
guess I'll at least try preempt_thresh=224 to see how that works
for me. -- George



I found that preempt_thresh=0 cannot be used in practice:
When I try to do this on my quadcode desktop, and then start four 
endless-loops to get the cores busy, the (internet)radio will have a 
dropout every 2-3 seconds (and there is nothing else running, just a 
sleeping icewm and a mostly sleeping firefox)!


So, the (SMP) system *depends* on preemption, it cannot handle streaming 
data without it. (@George: Your buildworld test is pure batch load, and 
may not be bothered by this effect.)



I think the problem is *not* to be solved by finding a good setting for
preempt_thresh (or other tuneables). I think the problem lies deeper, 
and these tuneables only change its appearance.


I have worked out a writeup explaining my thoughts in detail, and I 
would be glad if You stay tuned and evaluate that.


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

Re: kern.sched.quantum: Creepy, sadistic scheduler

[Peter]

EBFE via freebsd-stable wrote:

On Tue, 17 Apr 2018 09:05:48 -0700
Freddie Cash  wrote:


# Tune for desktop usage
kern.sched.preempt_thresh=224

​Works quite nicely on a 4-core AMD Phenom-II X4 960T Processor
(3010.09-MHz K8-class CPU) running KDE4 using an Nvidia 210 GPU.


For interactive tasks, there is a "special" tunable:
% sysctl kern.sched.interact
kern.sched.interact: 10 # default is 30
% sysctl -d kern.sched.interact
kern.sched.interact: Interactivity score threshold

reducing the value from 30 to 10-15 keeps your gui/system responsive,
even under high load.


Yes, this may improve the "irresponsive-desktop" problem. Because 
threads that are scored interactive, are run as realtime threads, ahead 
of all regular workload queues.
But it will likely not solve the problem described by George, having two 
competing batch jobs. And for my problem as described at the beginning
of the thread, I could probably tune so far that my "worker" thread 
would be considered interactive, but then it would just toggle between
realtime and timesharing queues - and while this may make things better, 
it will probably not lead to a smooth system behaviour.


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

[Bug 227603] [panic] r323477: Sleeping thread owns a non-sleepable lock

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227603

Matthew Macy  changed:

   What|Removed |Added

 CC||mm...@nextbsd.org

--- Comment #1 from Matthew Macy  ---
This is fixed in HEAD. I'll ask shurd to MFC the fix.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

vputx: usecount not zero for vnode

[Eugene M. Zheganin]

Hello,


what is this panic, got it just recently on a fresh -STABLE r332466:

Apr 18 17:52:39 san1 kernel: vputx: usecount not zero for vnode
Apr 18 17:52:39 san1 kernel: 0xf80f4d7d1760: tag devfs, type VCHR
Apr 18 17:52:39 san1 kernel: usecount -1, writecount -1, refcount 0


"vputx: usecount not zero for vnode" can be fund in just one place, 
/usr/src/sys/kern/vfs_subr.c, and it's followed by the panic() syscall.


Unfortunately, I have no crashdump of it (though I usually get 
crashdumps on this machine).



Eugene.

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

stable/11 r321309 loader.efi loader failed

[叔坤 吴]

greeting listers 
Its a duplicated mail due to mail list can’t attached pics.
stable/11 r321309 loader.efi recognize efipart as new disk on MacBook pro?
the error photos link below:
http://sw.gddsn.org.cn/jopens/test/IMG_6123.JPG 

http://sw.gddsn.org.cn/jopens/test/IMG_6126.JPG 

http://sw.gddsn.org.cn/jopens/test/IMG_6130.JPG 


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

[Bug 227603] [panic] r323477: Sleeping thread owns a non-sleepable lock

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227603

Bug ID: 227603
   Summary: [panic] r323477: Sleeping thread owns a non-sleepable
lock
   Product: Base System
   Version: 11.1-STABLE
  Hardware: Any
OS: Any
Status: New
  Keywords: crash
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: mjo...@freebsd.org
  Reporter: eu...@freebsd.org
CC: n...@freebsd.org, sta...@freebsd.org

Created attachment 192611
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=192611=edit
kgdb backtrace

The change https://svnweb.freebsd.org/base?view=revision=r323477 makes
it possible for kernel thread to sleep on sx lock in vlan_ioctl() function
while holding mutex bpf_mtx that is prohibited and leads to panic.

kgdb session is attached.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"