Re: Scheduler hack for multi-threaded processes

Hey, On Mon, Mar 28, 2016 at 02:00:13PM +0200, Alexandre Ratchov wrote: > do you mean that sound stuttes if the diff is applied but doesn't > stutter without the diff? Stuttering may have been an exaggeration. It's more of a short, bassy click than a stutter, really. Could be that it already

Re: Scheduler hack for multi-threaded processes

On Mon, Mar 28, 2016 at 12:41:01PM +0200, Henrik Friedrichsen wrote: > Can confirm all the reports regarding desktop apps becoming more > responsive. I do, however, experience sound stutters, e.g. when playing > music in the browser (Google Play Music) or movies with mpv. do you mean that sound

Re: Scheduler hack for multi-threaded processes

Can confirm all the reports regarding desktop apps becoming more responsive. I do, however, experience sound stutters, e.g. when playing music in the browser (Google Play Music) or movies with mpv. Interestingly, this does not seem to happen when playing YouTube videos.

Re: Scheduler hack for multi-threaded processes

On Thu, Mar 24, 2016 at 12:09:39PM +, Edd Barrett wrote: > On Wed, Mar 23, 2016 at 09:35:50PM +0100, Mark Kettenis wrote: > > So here is a diff that keeps yield() the same and adds the code in the > > sched_yield(2) implementation instead. > > I'm going to now run with this diff for a while.

Re: Scheduler hack for multi-threaded processes

On 2016/03/27 14:32, Mark Kettenis wrote: > > From: attila > > Date: Sat, 26 Mar 2016 17:47:38 -0600 > > > > Jyri Hovila [Turvamies.fi] writes: > > > > > I can report significant usability improvement on a single core > > > ThinkPad T42 and a

Re: Scheduler hack for multi-threaded processes

> From: attila > Date: Sat, 26 Mar 2016 17:47:38 -0600 > > Jyri Hovila [Turvamies.fi] writes: > > > I can report significant usability improvement on a single core > > ThinkPad T42 and a dual core ThinkPad X60. > > I hate to crap on this

Re: Scheduler hack for multi-threaded processes

27 марта 2016 г. 11:05 пользователь "Stefan Sperling" написал: > > On Sat, Mar 26, 2016 at 05:47:38PM -0600, attila wrote: > > Now it will be a challenge to see if I can cvs up, back out the patch > > and build a kernel without ringing the bell (100DegC). I freely admit > > this

Re: Scheduler hack for multi-threaded processes

On Sat, Mar 26, 2016 at 05:47:38PM -0600, attila wrote: > > Now it will be a challenge to see if I can cvs up, back out the patch > and build a kernel without ringing the bell (100DegC). boot obsd ? -- Matthieu Herrb signature.asc Description: PGP signature

Re: Scheduler hack for multi-threaded processes

On Sat, Mar 26, 2016 at 05:47:38PM -0600, attila wrote: > Now it will be a challenge to see if I can cvs up, back out the patch > and build a kernel without ringing the bell (100DegC). I freely admit > this is an old, P.O.S. laptop and that there might be some HW issue Did you check for dust in

Re: Scheduler hack for multi-threaded processes

On Sat, Mar 26, 2016 at 7:47 PM, attila wrote: > > Jyri Hovila [Turvamies.fi] writes: > >> I can report significant usability improvement on a single core ThinkPad T42 >> and a dual core ThinkPad X60. >> > > I hate to crap on this wonderful

Re: Scheduler hack for multi-threaded processes

Jyri Hovila [Turvamies.fi] writes: > I can report significant usability improvement on a single core ThinkPad T42 > and a dual core ThinkPad X60. > I hate to crap on this wonderful parade, but on my T60 (i386, dmesg at bottom) running 25 march snap the heat has

Re: Scheduler hack for multi-threaded processes

I can report significant usability improvement on a single core ThinkPad T42 and a dual core ThinkPad X60. It's not just "the videos in Firefox" - everything works *so* much more fluently with the patch there's no way I would go back living without it. I know a hack is a hack and I know there

Re: Scheduler hack for multi-threaded processes

> Date: Wed, 23 Mar 2016 22:16:36 +0100 > From: Martin Pieuchot > > On 23/03/16(Wed) 21:35, Mark Kettenis wrote: > > > Date: Mon, 21 Mar 2016 16:51:16 +0100 (CET) > > > From: Mark Kettenis > > > > > > This doesn't only change the sched_yield()

Re: Scheduler hack for multi-threaded processes

On 23/03/16(Wed) 23:58, Alexandre Ratchov wrote: > On Wed, Mar 23, 2016 at 09:35:50PM +0100, Mark Kettenis wrote: > > > > > > This doesn't only change the sched_yield() behaviour, but also > > > modifies how in-kernel yield() calls behave for threaded processes. > > > That is probably not right.

Re: Scheduler hack for multi-threaded processes

On Wed, Mar 23, 2016 at 09:35:50PM +0100, Mark Kettenis wrote: > So here is a diff that keeps yield() the same and adds the code in the > sched_yield(2) implementation instead. I'm going to now run with this diff for a while. On first glance, browser performance is good. Video seems to work well

Re: Scheduler hack for multi-threaded processes

> > Even if one day we fix the "browsers problem" in the thread > > library, I think this diff will remain necessary to handle > > processes calling sched_yield() in a loop, i.e. processes that are > > spinning. > > > Complete and utter hack: penalize processes or threads on > #system calls/time

Re: Scheduler hack for multi-threaded processes

On 03/23/2016 18:58, Alexandre Ratchov wrote: On Wed, Mar 23, 2016 at 09:35:50PM +0100, Mark Kettenis wrote: This doesn't only change the sched_yield() behaviour, but also modifies how in-kernel yield() calls behave for threaded processes. That is probably not right. So here is a diff that

Re: Scheduler hack for multi-threaded processes

On Wed, Mar 23, 2016 at 09:35:50PM +0100, Mark Kettenis wrote: > > > > This doesn't only change the sched_yield() behaviour, but also > > modifies how in-kernel yield() calls behave for threaded processes. > > That is probably not right. > > So here is a diff that keeps yield() the same and adds

Re: Scheduler hack for multi-threaded processes

On Wed, Mar 23, 2016 at 06:18:59PM -0400, Ted Unangst wrote: > Mark Kettenis wrote: > > So here is a diff that keeps yield() the same and adds the code in the > > sched_yield(2) implementation instead. It also changes the logic that > > picks the priority to walk the complete threads listand pick

Re: Scheduler hack for multi-threaded processes

Mark Kettenis wrote: > So here is a diff that keeps yield() the same and adds the code in the > sched_yield(2) implementation instead. It also changes the logic that > picks the priority to walk the complete threads listand pick the > highest priotity of all the threads. That should be enough to

Re: Scheduler hack for multi-threaded processes

On 23/03/16(Wed) 21:35, Mark Kettenis wrote: > > Date: Mon, 21 Mar 2016 16:51:16 +0100 (CET) > > From: Mark Kettenis > > > > > Date: Sat, 19 Mar 2016 13:53:07 +0100 > > > From: Martin Pieuchot > > > > > > Applications using multiple threads often call

Re: Scheduler hack for multi-threaded processes

> Date: Mon, 21 Mar 2016 16:51:16 +0100 (CET) > From: Mark Kettenis > > > Date: Sat, 19 Mar 2016 13:53:07 +0100 > > From: Martin Pieuchot > > > > Applications using multiple threads often call sched_yield(2) to > > indicate that one of the threads

Re: Scheduler hack for multi-threaded processes

On Tue, Mar 22, 2016 at 10:00 AM, Douglas Ray wrote: > On 21/03/16 11:29 AM, Mark Kettenis wrote: > >> From: Amit Kulkarni >>> Date: Sun, 20 Mar 2016 17:57:49 -0500 >>> >> ... > >> +1. Previously, when I did a cvs update with original scheduler code, >>>

Re: Scheduler hack for multi-threaded processes

Douglas Ray wrote: > On 21/03/16 11:29 AM, Mark Kettenis wrote: > >>From: Amit Kulkarni > >>Date: Sun, 20 Mar 2016 17:57:49 -0500 > ... > >>+1. Previously, when I did a cvs update with original scheduler code, doing > >>the ports update the machine always froze solid while

Re: Scheduler hack for multi-threaded processes

> >> IMHO, this patch should go in! > > > > No. It's a hack. It points out aproblem that should be investigated > > deeper. > > > > If it gives a significant performance improvement but is too distant > from a real solution, maybe it could be worth distributing in > package(s) form. > > The

Re: Scheduler hack for multi-threaded processes

On 21/03/16 11:29 AM, Mark Kettenis wrote: From: Amit Kulkarni Date: Sun, 20 Mar 2016 17:57:49 -0500 ... +1. Previously, when I did a cvs update with original scheduler code, doing the ports update the machine always froze solid while doing cvs update, taking 3 minutes to

Re: Scheduler hack for multi-threaded processes

> Date: Sat, 19 Mar 2016 13:53:07 +0100 > From: Martin Pieuchot > > Applications using multiple threads often call sched_yield(2) to > indicate that one of the threads cannot make any progress because > it is waiting for a resource held by another one. > > One example of this

Re: Scheduler hack for multi-threaded processes

Am 03/21/16 um 01:29 schrieb Mark Kettenis: > > No. It's a hack. It points out aproblem that should be investigated > deeper. > Maybe that's not only thread related. This diff only makes a difference with multi-threaded processes. It may be worth considering looking at the process level as

Re: Scheduler hack for multi-threaded processes

> From: Amit Kulkarni > Date: Sun, 20 Mar 2016 17:57:49 -0500 > > On Sat, Mar 19, 2016 at 4:35 PM, Bob wrote: > > > > > I'm also interested in hearing from more people using multi-threaded > >> applications. > >> > > > > I applied the patch to my old

Re: Scheduler hack for multi-threaded processes

On Sat, Mar 19, 2016 at 4:35 PM, Bob wrote: > > I'm also interested in hearing from more people using multi-threaded >> applications. >> > > I applied the patch to my old core duo p7570 running CURRENT/amd64. > Firefox is more responsive and youtube videos, previously

Re: Scheduler hack for multi-threaded processes

On Sun, Mar 20, 2016 at 09:04:22PM +0100, Norman Golisz wrote: > Hi Martin, > > On Sat Mar 19 2016 13:53, Martin Pieuchot wrote: > > I'm also interested in hearing from more people using multi-threaded > > applications. > > your patch - just like Michal's - improves the situation a lot. For now

Re: Scheduler hack for multi-threaded processes

Hi Martin, On Sat Mar 19 2016 13:53, Martin Pieuchot wrote: > I'm also interested in hearing from more people using multi-threaded > applications. your patch - just like Michal's - improves the situation a lot. Watching videos (HD) fullscreen in a browser without stuttering - the GUI stays

Re: Scheduler hack for multi-threaded processes

On Sat, Mar 19, 2016 at 01:53:07PM +0100, Martin Pieuchot wrote: > Applications using multiple threads often call sched_yield(2) to > indicate that one of the threads cannot make any progress because > it is waiting for a resource held by another one. > > One example of this scenario is the

Re: Scheduler hack for multi-threaded processes

> p_p->ps_threads (and p_thr_link) can only be modified by threads in > this process. The result is that the test here can't claim the > process is single-threaded when it's multi-threaded. (An "is MT" > result can go stale if there's no locking and the only other thread in > the process exits,

Re: Scheduler hack for multi-threaded processes

On Sat, Mar 19, 2016 at 01:53:07PM +0100, Martin Pieuchot wrote: > Applications using multiple threads often call sched_yield(2) to > indicate that one of the threads cannot make any progress because > it is waiting for a resource held by another one. > > One example of this scenario is the

Re: Scheduler hack for multi-threaded processes

I'm also interested in hearing from more people using multi-threaded applications. I applied the patch to my old core duo p7570 running CURRENT/amd64. Firefox is more responsive and youtube videos, previously impossible to watch, run smoothly, even in full screen. Sumultaneously did some

Re: Scheduler hack for multi-threaded processes

s/approves/improves/g

Re: Scheduler hack for multi-threaded processes

The java based Netbeans IDE performs a lot of things in the background using threads like indexing sources, downloading artifacts, unpacking archives, compiling sources in addition to the normal java background tasks like JIT compiling. This change approves UI responsiveness on my T60.

Re: Scheduler hack for multi-threaded processes

On Sat, Mar 19, 2016 at 01:53:07PM +0100, Martin Pieuchot wrote: > I experimented with various values for "p_priority" and this one is > the one that generates fewer # IPIs when watching a HD video on firefox. > Because yes, with this diff, now I can. YouTube on Firefox on ThinkPad T420: It's

Re: Scheduler hack for multi-threaded processes

On Sat, Mar 19, 2016 at 9:18 AM, Miod Vallat wrote: > >> I'd like to know if dereferencing ``p_p'' is safe without holding the >> KERNEL_LOCK. > > SCHED_LOCK is enough to access p_p->ps_threads, Uh, not quite. p_p itself is immutable for the life of a thread and can be

Re: Scheduler hack for multi-threaded processes

> I'd like to know if dereferencing ``p_p'' is safe without holding the > KERNEL_LOCK. SCHED_LOCK is enough to access p_p->ps_threads, The construct used to decide whether the process is multi-threaded already appears twice in sys/kern¸ and your diff adds a third instance. It is probably worth

Re: Scheduler hack for multi-threaded processes

On Sat, Mar 19, 2016 at 01:53:07PM +0100, Martin Pieuchot wrote: > I experimented with various values for "p_priority" and this one is > the one that generates fewer # IPIs when watching a HD video on firefox. > Because yes, with this diff, now I can. Same result here: Video in firefox plays

Re: Scheduler hack for multi-threaded processes

On Sat, Mar 19, 2016 at 01:53:07PM +0100, Martin Pieuchot wrote: > I experimented with various values for "p_priority" and this one is > the one that generates fewer # IPIs when watching a HD video on firefox. > Because yes, with this diff, now I can. Works well here in firefox too. Will run