Scheduler hack for multi-threaded processes

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Scheduler hack for multi-threaded processes

Michael McConville-3
Douglas Ray wrote:

> On 21/03/16 11:29 AM, Mark Kettenis wrote:
> >>From: Amit Kulkarni <[hidden email]>
> >>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 recover. This time with Martin's patch, the freezing
> >>period seems to have decreased quite a bit, although the freeze still
> >>happens. Stefan's amap diff and Bob's VFS/UVM diff also seems to have a
> >>made a difference.
> >>
> >>Pentium G2020 2.9GHz dual core Ivy bridge 22nm... 8 GB RAM
> >>
> >>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 team then has the option to actively promote it, or not; and
> the package could be updated as new refinements are found.

It's kernel code, you can't package it.

Reply | Threaded
Open this post in threaded view
|

Re: Scheduler hack for multi-threaded processes

Amit Kulkarni-5
In reply to this post by Douglas Ray
On Tue, Mar 22, 2016 at 10:00 AM, Douglas Ray <[hidden email]> wrote:

> On 21/03/16 11:29 AM, Mark Kettenis wrote:
>
>> From: Amit Kulkarni <[hidden email]>
>>> 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 recover. This time with Martin's patch, the freezing
>>> period seems to have decreased quite a bit, although the freeze still
>>> happens. Stefan's amap diff and Bob's VFS/UVM diff also seems to have a
>>> made a difference.
>>>
>>> Pentium G2020 2.9GHz dual core Ivy bridge 22nm... 8 GB RAM
>>>
>>> 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 team then has the option to actively promote it, or not; and
> the package could be updated as new refinements are found.
>
>
I am not sure if you know how the OpenBSD team operates. They call a hack a
hack and will do it right. I am thankful that Michal pointed out a
deficiency in our current implementation, and Martin reduced the test case.
That will help to figure out where the problem(s) is/are. To repeat the
team will do it right.

Thanks
Reply | Threaded
Open this post in threaded view
|

Re: Scheduler hack for multi-threaded processes

Mark Kettenis
In reply to this post by Mark Kettenis
> Date: Mon, 21 Mar 2016 16:51:16 +0100 (CET)
> From: Mark Kettenis <[hidden email]>
>
> > Date: Sat, 19 Mar 2016 13:53:07 +0100
> > From: Martin Pieuchot <[hidden email]>
> >
> > 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 _spinlock() implementation of
> > our librthread.  But if you look on https://codesearch.debian.net
> > you can find much more use cases, notably MySQL, PostgreSQL, JDK,
> > libreoffice, etc.
> >
> > Now the problem with our current scheduler is that the priority of
> > a thread decreases when it is the "curproc" of a CPU.  So the threads
> > that don't run and sched_yield(2) end up having a higher priority than
> > the thread holding the resource.  Which means that it's really hard for
> > such multi-threaded applications to make progress, resulting in a lot of
> > IPIs numbers.
> > That'd also explain why if you have a more CPUs, let's say 4 instead
> > of 2, your application will more likely make some progress and you'll
> > see less sluttering/freezing.
> >
> > So what the diff below does is that it penalizes the threads from
> > multi-threaded applications such that progress can be made.  It is
> > inspired from the recent scheduler work done by Michal Mazurek on
> > tech@.
> >
> > 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.
> >
> > I'd like to know if dereferencing ``p_p'' is safe without holding the
> > KERNEL_LOCK.
> >
> > I'm also interested in hearing from more people using multi-threaded
> > applications.
>
> 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 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 make
sure the calling thread is scheduled behind all other threads from the
same process.  That does require us to grab the kernel lock though.
So this removes NOLOCK from sched_yield(2).  I don't think that is a
big issue.

Still improves video playback in firefox on my x1.


Index: syscalls.master
===================================================================
RCS file: /cvs/src/sys/kern/syscalls.master,v
retrieving revision 1.167
diff -u -p -r1.167 syscalls.master
--- syscalls.master 21 Mar 2016 22:41:29 -0000 1.167
+++ syscalls.master 23 Mar 2016 20:33:45 -0000
@@ -514,7 +514,7 @@
 #else
 297 UNIMPL
 #endif
-298 STD NOLOCK { int sys_sched_yield(void); }
+298 STD { int sys_sched_yield(void); }
 299 STD NOLOCK { pid_t sys_getthrid(void); }
 300 OBSOL t32___thrsleep
 301 STD { int sys___thrwakeup(const volatile void *ident, \
Index: kern_synch.c
===================================================================
RCS file: /cvs/src/sys/kern/kern_synch.c,v
retrieving revision 1.129
diff -u -p -r1.129 kern_synch.c
--- kern_synch.c 9 Mar 2016 13:38:50 -0000 1.129
+++ kern_synch.c 23 Mar 2016 20:33:45 -0000
@@ -1,4 +1,4 @@
-/* $OpenBSD: kern_synch.c,v 1.129 2016/03/09 13:38:50 mpi Exp $ */
+/* $openbsd: kern_synch.c,v 1.129 2016/03/09 13:38:50 mpi Exp $ */
 /* $NetBSD: kern_synch.c,v 1.37 1996/04/22 01:38:37 christos Exp $ */
 
 /*
@@ -432,7 +432,24 @@ wakeup(const volatile void *chan)
 int
 sys_sched_yield(struct proc *p, void *v, register_t *retval)
 {
- yield();
+ struct proc *q;
+ int s;
+
+ SCHED_LOCK(s);
+ /*
+ * If one of the threads of a multi-threaded process called
+ * sched_yield(2), drop its priority to ensure its siblings
+ * can make some progress.
+ */
+ p->p_priority = p->p_usrpri;
+ TAILQ_FOREACH(q, &p->p_p->ps_threads, p_thr_link)
+ p->p_priority = max(p->p_priority, q->p_priority);
+ p->p_stat = SRUN;
+ setrunqueue(p);
+ p->p_ru.ru_nvcsw++;
+ mi_switch();
+ SCHED_UNLOCK(s);
+
  return (0);
 }
 

Reply | Threaded
Open this post in threaded view
|

Re: Scheduler hack for multi-threaded processes

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 <[hidden email]>
> >
> > > Date: Sat, 19 Mar 2016 13:53:07 +0100
> > > From: Martin Pieuchot <[hidden email]>
> > >
> > > 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 _spinlock() implementation of
> > > our librthread.  But if you look on https://codesearch.debian.net
> > > you can find much more use cases, notably MySQL, PostgreSQL, JDK,
> > > libreoffice, etc.
> > >
> > > Now the problem with our current scheduler is that the priority of
> > > a thread decreases when it is the "curproc" of a CPU.  So the threads
> > > that don't run and sched_yield(2) end up having a higher priority than
> > > the thread holding the resource.  Which means that it's really hard for
> > > such multi-threaded applications to make progress, resulting in a lot of
> > > IPIs numbers.
> > > That'd also explain why if you have a more CPUs, let's say 4 instead
> > > of 2, your application will more likely make some progress and you'll
> > > see less sluttering/freezing.
> > >
> > > So what the diff below does is that it penalizes the threads from
> > > multi-threaded applications such that progress can be made.  It is
> > > inspired from the recent scheduler work done by Michal Mazurek on
> > > tech@.
> > >
> > > 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.
> > >
> > > I'd like to know if dereferencing ``p_p'' is safe without holding the
> > > KERNEL_LOCK.
> > >
> > > I'm also interested in hearing from more people using multi-threaded
> > > applications.
> >
> > 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 the code in the
> sched_yield(2) implementation instead.

I'm not a big fan of code duplication, what about checking for
p_usrpri >= PUSER 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 make
> sure the calling thread is scheduled behind all other threads from the
> same process.  That does require us to grab the kernel lock though.
> So this removes NOLOCK from sched_yield(2).  I don't think that is a
> big issue.
>
> Still improves video playback in firefox on my x1.

This is another kind of hack :)  It's certainly less intrusive but
I'm still not sure if we want that.  Reducing the priority of a
thread to the worst priority of its siblings might still not be
enough.

Now I'd like to know how many times sched_yield() really triggers a
context switch for threaded programs with this version of the diff.

Without any diff I observed that only 20 to 25% of the sched_yield()
calls made by firefox result in a different thread being chosen by
mi_switch().  Somethings tell me that per-CPU runqueues are to blame
here.

> Index: syscalls.master
> ===================================================================
> RCS file: /cvs/src/sys/kern/syscalls.master,v
> retrieving revision 1.167
> diff -u -p -r1.167 syscalls.master
> --- syscalls.master 21 Mar 2016 22:41:29 -0000 1.167
> +++ syscalls.master 23 Mar 2016 20:33:45 -0000
> @@ -514,7 +514,7 @@
>  #else
>  297 UNIMPL
>  #endif
> -298 STD NOLOCK { int sys_sched_yield(void); }
> +298 STD { int sys_sched_yield(void); }
>  299 STD NOLOCK { pid_t sys_getthrid(void); }
>  300 OBSOL t32___thrsleep
>  301 STD { int sys___thrwakeup(const volatile void *ident, \
> Index: kern_synch.c
> ===================================================================
> RCS file: /cvs/src/sys/kern/kern_synch.c,v
> retrieving revision 1.129
> diff -u -p -r1.129 kern_synch.c
> --- kern_synch.c 9 Mar 2016 13:38:50 -0000 1.129
> +++ kern_synch.c 23 Mar 2016 20:33:45 -0000
> @@ -1,4 +1,4 @@
> -/* $OpenBSD: kern_synch.c,v 1.129 2016/03/09 13:38:50 mpi Exp $ */
> +/* $openbsd: kern_synch.c,v 1.129 2016/03/09 13:38:50 mpi Exp $ */
>  /* $NetBSD: kern_synch.c,v 1.37 1996/04/22 01:38:37 christos Exp $ */
>  
>  /*
> @@ -432,7 +432,24 @@ wakeup(const volatile void *chan)
>  int
>  sys_sched_yield(struct proc *p, void *v, register_t *retval)
>  {
> - yield();
> + struct proc *q;
> + int s;
> +
> + SCHED_LOCK(s);
> + /*
> + * If one of the threads of a multi-threaded process called
> + * sched_yield(2), drop its priority to ensure its siblings
> + * can make some progress.
> + */
> + p->p_priority = p->p_usrpri;
> + TAILQ_FOREACH(q, &p->p_p->ps_threads, p_thr_link)
> + p->p_priority = max(p->p_priority, q->p_priority);
> + p->p_stat = SRUN;
> + setrunqueue(p);
> + p->p_ru.ru_nvcsw++;
> + mi_switch();
> + SCHED_UNLOCK(s);
> +
>   return (0);
>  }
>  
>

Reply | Threaded
Open this post in threaded view
|

Re: Scheduler hack for multi-threaded processes

Ted Unangst-6
In reply to this post by Mark Kettenis
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 make
> sure the calling thread is scheduled behind all other threads from the
> same process.  That does require us to grab the kernel lock though.
> So this removes NOLOCK from sched_yield(2).  I don't think that is a
> big issue.

this does sound a little better. in theory we should be gifting priority to
the thread with the lock, but if we don't know who... more of this lock
business needs to go kernel side i suspect. still, maybe we can do the opposite
and raise other threads to this thread's priority?

Reply | Threaded
Open this post in threaded view
|

Re: Scheduler hack for multi-threaded processes

Alexandre Ratchov-2
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 the
> > highest priotity of all the threads.  That should be enough to make
> > sure the calling thread is scheduled behind all other threads from the
> > same process.  That does require us to grab the kernel lock though.
> > So this removes NOLOCK from sched_yield(2).  I don't think that is a
> > big issue.
>
> this does sound a little better. in theory we should be gifting priority to
> the thread with the lock, but if we don't know who... more of this lock
> business needs to go kernel side i suspect. still, maybe we can do the opposite
> and raise other threads to this thread's priority?

AFAICS, raised priority is for interactive (aka io-bound) threads.
Processes spinning (here by calling sched_yield()) desserve lower
priority, as do any cpu-bound thread.

Reply | Threaded
Open this post in threaded view
|

Re: Scheduler hack for multi-threaded processes

Alexandre Ratchov-2
In reply to this post by Mark Kettenis
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 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 make
> sure the calling thread is scheduled behind all other threads from the
> same process.  That does require us to grab the kernel lock though.
> So this removes NOLOCK from sched_yield(2).  I don't think that is a
> big issue.

I used to think that this is a hack, but now i think this is
necessary.

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.

Reply | Threaded
Open this post in threaded view
|

Re: Scheduler hack for multi-threaded processes

gwes-2


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 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 make
>> sure the calling thread is scheduled behind all other threads from the
>> same process.  That does require us to grab the kernel lock though.
>> So this removes NOLOCK from sched_yield(2).  I don't think that is a
>> big issue.
> I used to think that this is a hack, but now i think this is
> necessary.
>
> 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 period. Syscalls are more expensive than
normal execution because of locking which blocks other
processes. Reset the counter when process transitions from
inactive->active.

I know that some systems have implemented this type of
input to scheduling according to use of intangible resources.

Geoff Steckel

Reply | Threaded
Open this post in threaded view
|

Re: Scheduler hack for multi-threaded processes

Theo de Raadt
> > 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 period. Syscalls are more expensive than
> normal execution because of locking which blocks other
> processes. Reset the counter when process transitions from
> inactive->active.

Yeah..... punish processes when they call the code most likely
to be efficient (that is -- kernel code).

Thanks for the advice, but you don't have a clue.

Reply | Threaded
Open this post in threaded view
|

Re: Scheduler hack for multi-threaded processes

Edd Barrett-3
In reply to this post by Mark Kettenis
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 in firefox.

Thanks.

--
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Reply | Threaded
Open this post in threaded view
|

Re: Scheduler hack for multi-threaded processes

Martin Pieuchot
In reply to this post by Alexandre Ratchov-2
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.
> >
> > 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 make
> > sure the calling thread is scheduled behind all other threads from the
> > same process.  That does require us to grab the kernel lock though.
> > So this removes NOLOCK from sched_yield(2).  I don't think that is a
> > big issue.
>
> I used to think that this is a hack, but now i think this is
> necessary.

I agree, I think it's a step forward.

I realized that PUSER does not mean what I though, so I'd suggest
checking for P_SYSTEM to not duplicate the code.

As for the NOLOCK we could put it back by computing the lowest priority
in schedcpu() and storing it in the process.

Index: kern/sched_bsd.c
===================================================================
RCS file: /cvs/src/sys/kern/sched_bsd.c,v
retrieving revision 1.43
diff -u -p -r1.43 sched_bsd.c
--- kern/sched_bsd.c 9 Mar 2016 13:38:50 -0000 1.43
+++ kern/sched_bsd.c 24 Mar 2016 12:53:29 -0000
@@ -294,11 +294,20 @@ updatepri(struct proc *p)
 void
 yield(void)
 {
- struct proc *p = curproc;
+ struct proc *q, *p = curproc;
  int s;
 
  SCHED_LOCK(s);
  p->p_priority = p->p_usrpri;
+ /*
+ * If one of the threads of a multi-threaded process called
+ * sched_yield(2), drop its priority to ensure its siblings
+ * can make some progress.
+ */
+ if ((p->p_flag & P_SYSTEM) == 0) {
+ TAILQ_FOREACH(q, &p->p_p->ps_threads, p_thr_link)
+ p->p_priority = max(p->p_priority, q->p_priority);
+ }
  p->p_stat = SRUN;
  setrunqueue(p);
  p->p_ru.ru_nvcsw++;
Index: kern/syscalls.master
===================================================================
RCS file: /cvs/src/sys/kern/syscalls.master,v
retrieving revision 1.167
diff -u -p -r1.167 syscalls.master
--- kern/syscalls.master 21 Mar 2016 22:41:29 -0000 1.167
+++ kern/syscalls.master 24 Mar 2016 12:23:20 -0000
@@ -514,7 +514,7 @@
 #else
 297 UNIMPL
 #endif
-298 STD NOLOCK { int sys_sched_yield(void); }
+298 STD { int sys_sched_yield(void); }
 299 STD NOLOCK { pid_t sys_getthrid(void); }
 300 OBSOL t32___thrsleep
 301 STD { int sys___thrwakeup(const volatile void *ident, \

Reply | Threaded
Open this post in threaded view
|

Re: Scheduler hack for multi-threaded processes

Mark Kettenis
In reply to this post by Martin Pieuchot
> Date: Wed, 23 Mar 2016 22:16:36 +0100
> From: Martin Pieuchot <[hidden email]>
>
> On 23/03/16(Wed) 21:35, Mark Kettenis wrote:
> > > Date: Mon, 21 Mar 2016 16:51:16 +0100 (CET)
> > > From: Mark Kettenis <[hidden email]>
> > >
> > > 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 the code in the
> > sched_yield(2) implementation instead.
>
> I'm not a big fan of code duplication, what about checking for
> p_usrpri >= PUSER instead?

I think we really want to keep the existing yield() semantics for
userland processes running inside the kernel as well.  So that
wouldn't work, even apart from the fact that the p_usrpri >= PUSER
check is a bit dodgy.  So I think code duplication is a unavoidable
here.

> >                                         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 make
> > sure the calling thread is scheduled behind all other threads from the
> > same process.  That does require us to grab the kernel lock though.
> > So this removes NOLOCK from sched_yield(2).  I don't think that is a
> > big issue.
> >
> > Still improves video playback in firefox on my x1.
>
> This is another kind of hack :)  It's certainly less intrusive but
> I'm still not sure if we want that.  Reducing the priority of a
> thread to the worst priority of its siblings might still not be
> enough.

I don't disagree with you, although our current implementation of
sched_yield(2) *is* simewhat broken as it doesn't guarantee that the
current thread will land at the tail of the list of threads running at
the same priority (priority as set by the user through setpriority(2)).

> Now I'd like to know how many times sched_yield() really triggers a
> context switch for threaded programs with this version of the diff.

Do you have a diff to measure this?

> Without any diff I observed that only 20 to 25% of the sched_yield()
> calls made by firefox result in a different thread being chosen by
> mi_switch().  Somethings tell me that per-CPU runqueues are to blame
> here.

I'm not sure the per-CPU runqueues are that much of a problem.
Spinning on sched_yield() may be somewhat suboptimal, but it shouldn't
really affect the speed at which things run as long as the thread that
holds the spinlock is guaranteed to make progress on some other CPU.

Ultimately we want to reduce the contention; and to first order that
means a more thread-friendly malloc implementention.  So I encourage
folks to look at otto's diff.

But there will always be some lock contention.  So improving the
__thrsleep/__thrwakeup interface will be important as well.
Unfortunately the atomic-operation challenged hardware platforms make
this non-trivial.

With those issues fixed we might be able to implement sched_yield(2)
in a slightly less pessimistic way.

Cheers,

Mark

> > Index: syscalls.master
> > ===================================================================
> > RCS file: /cvs/src/sys/kern/syscalls.master,v
> > retrieving revision 1.167
> > diff -u -p -r1.167 syscalls.master
> > --- syscalls.master 21 Mar 2016 22:41:29 -0000 1.167
> > +++ syscalls.master 23 Mar 2016 20:33:45 -0000
> > @@ -514,7 +514,7 @@
> >  #else
> >  297 UNIMPL
> >  #endif
> > -298 STD NOLOCK { int sys_sched_yield(void); }
> > +298 STD { int sys_sched_yield(void); }
> >  299 STD NOLOCK { pid_t sys_getthrid(void); }
> >  300 OBSOL t32___thrsleep
> >  301 STD { int sys___thrwakeup(const volatile void *ident, \
> > Index: kern_synch.c
> > ===================================================================
> > RCS file: /cvs/src/sys/kern/kern_synch.c,v
> > retrieving revision 1.129
> > diff -u -p -r1.129 kern_synch.c
> > --- kern_synch.c 9 Mar 2016 13:38:50 -0000 1.129
> > +++ kern_synch.c 23 Mar 2016 20:33:45 -0000
> > @@ -1,4 +1,4 @@
> > -/* $OpenBSD: kern_synch.c,v 1.129 2016/03/09 13:38:50 mpi Exp $ */
> > +/* $openbsd: kern_synch.c,v 1.129 2016/03/09 13:38:50 mpi Exp $ */
> >  /* $NetBSD: kern_synch.c,v 1.37 1996/04/22 01:38:37 christos Exp $ */
> >  
> >  /*
> > @@ -432,7 +432,24 @@ wakeup(const volatile void *chan)
> >  int
> >  sys_sched_yield(struct proc *p, void *v, register_t *retval)
> >  {
> > - yield();
> > + struct proc *q;
> > + int s;
> > +
> > + SCHED_LOCK(s);
> > + /*
> > + * If one of the threads of a multi-threaded process called
> > + * sched_yield(2), drop its priority to ensure its siblings
> > + * can make some progress.
> > + */
> > + p->p_priority = p->p_usrpri;
> > + TAILQ_FOREACH(q, &p->p_p->ps_threads, p_thr_link)
> > + p->p_priority = max(p->p_priority, q->p_priority);
> > + p->p_stat = SRUN;
> > + setrunqueue(p);
> > + p->p_ru.ru_nvcsw++;
> > + mi_switch();
> > + SCHED_UNLOCK(s);
> > +
> >   return (0);
> >  }
> >  
> >

Reply | Threaded
Open this post in threaded view
|

Re: Scheduler hack for multi-threaded processes

Jyri Hovila [Turvamies.fi]
In reply to this post by Martin Pieuchot
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 are many unknowns there, but at least from the perspective of a "normal" OpenBSD desktop user, this patch is an absolute must.

Let's not start a flame war here, just throwing in my five cents.

Kudos to Martin.

-j.

Reply | Threaded
Open this post in threaded view
|

Re: Scheduler hack for multi-threaded processes

attila

Jyri Hovila [Turvamies.fi] <[hidden email]> 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 bumped a full 10DegC from
what was "normal" before.  I'm sorry for the lack of science here and
I have no hard numbers w/wo patch yet but in the past my steady state
on this machine w/o firefox was something like 70DegC, w/just some
xterms and emacs (aka life).  Starting firefox generally added 10DegC
before I did anything at all and I always had to watch the heat and
kill firefox when we crossed 95DegC or Bad Things Happened; thus I
live with w3m in one hand and treat firefox as some kind of
luxury... tor-browser was, strangely, less hard on things but maybe
that's just because I never have too many tabs there (also, maybe
firefox-esr is a little lighter, not sure).

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
(fan seems fine but I haven't taken it apart and really looked).  It
does seem like the difference in the scheduler has a remarkable effect
on heat in my case.

Does anyone else see this?


> 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.

It never occurs to me to try watching videos in firefox.  I think I'm
just old.

> I know a hack is a hack and I know there are many unknowns there, but at least from the perspective of a "normal" OpenBSD desktop user, this patch is an absolute must.
>
> Let's not start a flame war here, just throwing in my five cents.

"Flame war" has added meaning in my case :-).

> Kudos to Martin.
>
> -j.

I appreciate all the great work as always.  OpenBSD rules... and yes,
I need a new laptop.

Pax, -A
--
http://haqistan.net/~attila | [hidden email] | 0x62A729CF

========================================================================

OpenBSD 5.9-current (GENERIC.MP) #1677: Fri Mar 25 14:19:24 MDT 2016
    [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM) Duo CPU T2400 @ 1.83GHz ("GenuineIntel" 686-class) 1.83 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF,SENSOR
real mem  = 2145730560 (2046MB)
avail mem = 2092142592 (1995MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 03/21/11, BIOS32 rev. 0 @ 0xfd6b0, SMBIOS rev. 2.4 @ 0xe0010 (68 entries)
bios0: vendor LENOVO version "79ETE7WW (2.27 )" date 03/21/2011
bios0: LENOVO 2008VRQ
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT SSDT SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) LURT(S3) DURT(S3) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) Duo CPU T2400 @ 1.83GHz ("GenuineIntel" 686-class) 1.83 GHz
cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF,SENSOR
ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xf0000000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus 4 (EXP2)
acpiprt5 at acpi0: bus 12 (EXP3)
acpiprt6 at acpi0: bus 21 (PCI1)
acpicpu0 at acpi0: !C3(250@17 io@0x1015), !C2(500@1 io@0x1014), C1(1000@1 halt), PSS
acpicpu1 at acpi0: !C3(250@17 io@0x1015), !C2(500@1 io@0x1014), C1(1000@1 halt), PSS
acpipwrres0 at acpi0: PUBS, resource for USB0, USB2, USB7
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 99 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model "42T4504" serial 41199 type LION oem "SANYO"
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK not docked (0)
bios0: ROM list: 0xc0000/0xfe00 0xd0000/0x1000 0xd1000/0x1000 0xdc000/0x4000! 0xe0000/0x10000!
cpu0: Enhanced SpeedStep 1829 MHz: speeds: 1833, 1333, 1000 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82945GM Host" rev 0x03
ppb0 at pci0 dev 1 function 0 "Intel 82945GM PCIE" rev 0x03: apic 1 int 16
pci1 at ppb0 bus 1
radeondrm0 at pci1 dev 0 function 0 "ATI Radeon Mobility X1400" rev 0x00
drm0 at radeondrm0
radeondrm0: apic 1 int 16
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi
azalia0: codecs: Analog Devices AD1981HD, Conexant/0x2bfa, using Analog Devices AD1981HD
audio0 at azalia0
ppb1 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 1 int 20
pci2 at ppb1 bus 2
em0 at pci2 dev 0 function 0 "Intel 82573L" rev 0x00: msi, address 00:1a:6b:66:61:9d
ppb2 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 1 int 21
pci3 at ppb2 bus 3
wpi0 at pci3 dev 0 function 0 "Intel PRO/Wireless 3945ABG" rev 0x02: msi, MoW1, address 00:1b:77:1c:4a:ed
ppb3 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x02: apic 1 int 22
pci4 at ppb3 bus 4
ppb4 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x02: apic 1 int 23
pci5 at ppb4 bus 12
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 1 int 16
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 1 int 17
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 1 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 1 int 19
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x02: apic 1 int 19
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb5 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xe2
pci6 at ppb5 bus 21
cbb0 at pci6 dev 0 function 0 "TI PCI1510 CardBus" rev 0x00: apic 1 int 16
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 22 device 0 cacheline 0x8, lattimer 0xb0
pcmcia0 at cardslot0
ichpcib0 at pci0 dev 31 function 0 "Intel 82801GBM LPC" rev 0x02: PM disabled
pciide0 at pci0 dev 31 function 1 "Intel 82801GB IDE" rev 0x02: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility
atapiscsi0 at pciide0 channel 0 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: <HL-DT-ST, DVDRAM GSA-4083N, 1.08> ATAPI 5/cdrom removable
cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
ahci0 at pci0 dev 31 function 2 "Intel 82801GBM AHCI" rev 0x02: msi, AHCI 1.1
ahci0: port 0: 1.5Gb/s
scsibus2 at ahci0: 32 targets
sd0 at scsibus2 targ 0 lun 0: <ATA, HTS721010G9SA00, MCZI> SCSI3 0/direct fixed t10.ATA_HTS721010G9SA00_MPCZN7Y0GVP8LL
sd0: 95396MB, 512 bytes/sector, 195371568 sectors
ichiic0 at pci0 dev 31 function 3 "Intel 82801GB SMBus" rev 0x02: apic 1 int 23
iic0 at ichiic0
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb4 at uhci3: USB revision 1.0
uhub4 at usb4 "Intel UHCI root hub" rev 1.00/1.00 addr 1
isa0 at ichpcib0
isadma0 at isa0
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
aps0 at isa0 port 0x1600/31
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
ugen0 at uhub4 port 2 "STMicroelectronics Biometric Coprocessor" rev 1.00/0.01 addr 2
vscsi0 at root
scsibus3 at vscsi0: 256 targets
softraid0 at root
scsibus4 at softraid0: 256 targets
root on sd0a (2dca00534335f096.a) swap on sd0b dump on sd0b
radeondrm0: 1400x1050
wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using wskbd0
wsdisplay0: screen 1-5 added (std, vt100 emulation)

Reply | Threaded
Open this post in threaded view
|

Re: Scheduler hack for multi-threaded processes

Adam Van Ymeren
On Sat, Mar 26, 2016 at 7:47 PM, attila <[hidden email]> wrote:

>
> Jyri Hovila [Turvamies.fi] <[hidden email]> 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 bumped a full 10DegC from
> what was "normal" before.  I'm sorry for the lack of science here and
> I have no hard numbers w/wo patch yet but in the past my steady state
> on this machine w/o firefox was something like 70DegC, w/just some
> xterms and emacs (aka life).  Starting firefox generally added 10DegC
> before I did anything at all and I always had to watch the heat and
> kill firefox when we crossed 95DegC or Bad Things Happened; thus I
> live with w3m in one hand and treat firefox as some kind of
> luxury... tor-browser was, strangely, less hard on things but maybe
> that's just because I never have too many tabs there (also, maybe
> firefox-esr is a little lighter, not sure).
>
> 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
> (fan seems fine but I haven't taken it apart and really looked).  It
> does seem like the difference in the scheduler has a remarkable effect
> on heat in my case.

Could you not use # apm -L to set keep the CPU at its lowest frequency setting?

>
> Does anyone else see this?
>
>
>> 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.
>
> It never occurs to me to try watching videos in firefox.  I think I'm
> just old.
>
>> I know a hack is a hack and I know there are many unknowns there, but at least from the perspective of a "normal" OpenBSD desktop user, this patch is an absolute must.
>>
>> Let's not start a flame war here, just throwing in my five cents.
>
> "Flame war" has added meaning in my case :-).
>
>> Kudos to Martin.
>>
>> -j.
>
> I appreciate all the great work as always.  OpenBSD rules... and yes,
> I need a new laptop.
>
> Pax, -A
> --
> http://haqistan.net/~attila | [hidden email] | 0x62A729CF
>
> ========================================================================
>
> OpenBSD 5.9-current (GENERIC.MP) #1677: Fri Mar 25 14:19:24 MDT 2016
>     [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC.MP
> cpu0: Intel(R) Core(TM) Duo CPU T2400 @ 1.83GHz ("GenuineIntel" 686-class) 1.83 GHz
> cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF,SENSOR
> real mem  = 2145730560 (2046MB)
> avail mem = 2092142592 (1995MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 03/21/11, BIOS32 rev. 0 @ 0xfd6b0, SMBIOS rev. 2.4 @ 0xe0010 (68 entries)
> bios0: vendor LENOVO version "79ETE7WW (2.27 )" date 03/21/2011
> bios0: LENOVO 2008VRQ
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT SSDT SSDT SSDT SSDT
> acpi0: wakeup devices LID_(S3) SLPB(S3) LURT(S3) DURT(S3) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiec0 at acpi0
> acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 166MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM) Duo CPU T2400 @ 1.83GHz ("GenuineIntel" 686-class) 1.83 GHz
> cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF,SENSOR
> ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 20, 24 pins
> ioapic0: misconfigured as apic 2, remapped to apid 1
> acpimcfg0 at acpi0 addr 0xf0000000, bus 0-63
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (AGP_)
> acpiprt2 at acpi0: bus 2 (EXP0)
> acpiprt3 at acpi0: bus 3 (EXP1)
> acpiprt4 at acpi0: bus 4 (EXP2)
> acpiprt5 at acpi0: bus 12 (EXP3)
> acpiprt6 at acpi0: bus 21 (PCI1)
> acpicpu0 at acpi0: !C3(250@17 io@0x1015), !C2(500@1 io@0x1014), C1(1000@1 halt), PSS
> acpicpu1 at acpi0: !C3(250@17 io@0x1015), !C2(500@1 io@0x1014), C1(1000@1 halt), PSS
> acpipwrres0 at acpi0: PUBS, resource for USB0, USB2, USB7
> acpitz0 at acpi0: critical temperature is 127 degC
> acpitz1 at acpi0: critical temperature is 99 degC
> acpibtn0 at acpi0: LID_
> acpibtn1 at acpi0: SLPB
> acpibat0 at acpi0: BAT0 model "42T4504" serial 41199 type LION oem "SANYO"
> acpibat1 at acpi0: BAT1 not present
> acpiac0 at acpi0: AC unit online
> acpithinkpad0 at acpi0
> acpidock0 at acpi0: GDCK not docked (0)
> bios0: ROM list: 0xc0000/0xfe00 0xd0000/0x1000 0xd1000/0x1000 0xdc000/0x4000! 0xe0000/0x10000!
> cpu0: Enhanced SpeedStep 1829 MHz: speeds: 1833, 1333, 1000 MHz
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Intel 82945GM Host" rev 0x03
> ppb0 at pci0 dev 1 function 0 "Intel 82945GM PCIE" rev 0x03: apic 1 int 16
> pci1 at ppb0 bus 1
> radeondrm0 at pci1 dev 0 function 0 "ATI Radeon Mobility X1400" rev 0x00
> drm0 at radeondrm0
> radeondrm0: apic 1 int 16
> azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi
> azalia0: codecs: Analog Devices AD1981HD, Conexant/0x2bfa, using Analog Devices AD1981HD
> audio0 at azalia0
> ppb1 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 1 int 20
> pci2 at ppb1 bus 2
> em0 at pci2 dev 0 function 0 "Intel 82573L" rev 0x00: msi, address 00:1a:6b:66:61:9d
> ppb2 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 1 int 21
> pci3 at ppb2 bus 3
> wpi0 at pci3 dev 0 function 0 "Intel PRO/Wireless 3945ABG" rev 0x02: msi, MoW1, address 00:1b:77:1c:4a:ed
> ppb3 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x02: apic 1 int 22
> pci4 at ppb3 bus 4
> ppb4 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x02: apic 1 int 23
> pci5 at ppb4 bus 12
> uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 1 int 16
> uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 1 int 17
> uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 1 int 18
> uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 1 int 19
> ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x02: apic 1 int 19
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
> ppb5 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xe2
> pci6 at ppb5 bus 21
> cbb0 at pci6 dev 0 function 0 "TI PCI1510 CardBus" rev 0x00: apic 1 int 16
> cardslot0 at cbb0 slot 0 flags 0
> cardbus0 at cardslot0: bus 22 device 0 cacheline 0x8, lattimer 0xb0
> pcmcia0 at cardslot0
> ichpcib0 at pci0 dev 31 function 0 "Intel 82801GBM LPC" rev 0x02: PM disabled
> pciide0 at pci0 dev 31 function 1 "Intel 82801GB IDE" rev 0x02: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility
> atapiscsi0 at pciide0 channel 0 drive 0
> scsibus1 at atapiscsi0: 2 targets
> cd0 at scsibus1 targ 0 lun 0: <HL-DT-ST, DVDRAM GSA-4083N, 1.08> ATAPI 5/cdrom removable
> cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
> pciide0: channel 1 ignored (disabled)
> ahci0 at pci0 dev 31 function 2 "Intel 82801GBM AHCI" rev 0x02: msi, AHCI 1.1
> ahci0: port 0: 1.5Gb/s
> scsibus2 at ahci0: 32 targets
> sd0 at scsibus2 targ 0 lun 0: <ATA, HTS721010G9SA00, MCZI> SCSI3 0/direct fixed t10.ATA_HTS721010G9SA00_MPCZN7Y0GVP8LL
> sd0: 95396MB, 512 bytes/sector, 195371568 sectors
> ichiic0 at pci0 dev 31 function 3 "Intel 82801GB SMBus" rev 0x02: apic 1 int 23
> iic0 at ichiic0
> usb1 at uhci0: USB revision 1.0
> uhub1 at usb1 "Intel UHCI root hub" rev 1.00/1.00 addr 1
> usb2 at uhci1: USB revision 1.0
> uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1
> usb3 at uhci2: USB revision 1.0
> uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1
> usb4 at uhci3: USB revision 1.0
> uhub4 at usb4 "Intel UHCI root hub" rev 1.00/1.00 addr 1
> isa0 at ichpcib0
> isadma0 at isa0
> com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard
> pms0 at pckbc0 (aux slot)
> wsmouse0 at pms0 mux 0
> pcppi0 at isa0 port 0x61
> spkr0 at pcppi0
> aps0 at isa0 port 0x1600/31
> npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
> ugen0 at uhub4 port 2 "STMicroelectronics Biometric Coprocessor" rev 1.00/0.01 addr 2
> vscsi0 at root
> scsibus3 at vscsi0: 256 targets
> softraid0 at root
> scsibus4 at softraid0: 256 targets
> root on sd0a (2dca00534335f096.a) swap on sd0b dump on sd0b
> radeondrm0: 1400x1050
> wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using wskbd0
> wsdisplay0: screen 1-5 added (std, vt100 emulation)
>

Reply | Threaded
Open this post in threaded view
|

Re: Scheduler hack for multi-threaded processes

Stefan Sperling-5
In reply to this post by attila
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 the fan vent?

I've had to treat my x60 with a hoover more than once after it had fallen
ill with a temperature...

Reply | Threaded
Open this post in threaded view
|

Re: Scheduler hack for multi-threaded processes

Matthieu Herrb-7
In reply to this post by attila
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 (476 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Scheduler hack for multi-threaded processes

Vadim Zhukov
In reply to this post by Stefan Sperling-5
27 марта 2016 г. 11:05 пользователь "Stefan Sperling" <[hidden email]>
написал:

>
> 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 the fan vent?
>
> I've had to treat my x60 with a hoover more than once after it had fallen
> ill with a temperature...

That's dangerous: you at least need fan cables from motherboard, to avoid
it generating electricity when spinning. I know two cases of killed this
way motherboards (not ThinkPad, but still).

--
WBR,
  Vadim Zhukov
Reply | Threaded
Open this post in threaded view
|

Re: Scheduler hack for multi-threaded processes

Mark Kettenis
In reply to this post by attila
> From: attila <[hidden email]>
> Date: Sat, 26 Mar 2016 17:47:38 -0600
>
> Jyri Hovila [Turvamies.fi] <[hidden email]> 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 bumped a full 10DegC from
> what was "normal" before.  I'm sorry for the lack of science here and
> I have no hard numbers w/wo patch yet but in the past my steady state
> on this machine w/o firefox was something like 70DegC, w/just some
> xterms and emacs (aka life).  Starting firefox generally added 10DegC
> before I did anything at all and I always had to watch the heat and
> kill firefox when we crossed 95DegC or Bad Things Happened; thus I
> live with w3m in one hand and treat firefox as some kind of
> luxury... tor-browser was, strangely, less hard on things but maybe
> that's just because I never have too many tabs there (also, maybe
> firefox-esr is a little lighter, not sure).
>
> 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
> (fan seems fine but I haven't taken it apart and really looked).  It
> does seem like the difference in the scheduler has a remarkable effect
> on heat in my case.

If you're not running any multi-threaded code the diff should have
zero impact.  And I expect the diff to actually decrease the CPU load
when running such code, and therefore lower the temperature.  This is
most likely a hardware issue, i.e. dust or a failing fan.

Reply | Threaded
Open this post in threaded view
|

Re: Scheduler hack for multi-threaded processes

Stuart Henderson
On 2016/03/27 14:32, Mark Kettenis wrote:

> > From: attila <[hidden email]>
> > Date: Sat, 26 Mar 2016 17:47:38 -0600
> >
> > Jyri Hovila [Turvamies.fi] <[hidden email]> 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 bumped a full 10DegC from
> > what was "normal" before.  I'm sorry for the lack of science here and
> > I have no hard numbers w/wo patch yet but in the past my steady state
> > on this machine w/o firefox was something like 70DegC, w/just some
> > xterms and emacs (aka life).  Starting firefox generally added 10DegC
> > before I did anything at all and I always had to watch the heat and
> > kill firefox when we crossed 95DegC or Bad Things Happened; thus I
> > live with w3m in one hand and treat firefox as some kind of
> > luxury... tor-browser was, strangely, less hard on things but maybe
> > that's just because I never have too many tabs there (also, maybe
> > firefox-esr is a little lighter, not sure).
> >
> > 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
> > (fan seems fine but I haven't taken it apart and really looked).  It
> > does seem like the difference in the scheduler has a remarkable effect
> > on heat in my case.
>
> If you're not running any multi-threaded code the diff should have
> zero impact.  And I expect the diff to actually decrease the CPU load
> when running such code, and therefore lower the temperature.  This is
> most likely a hardware issue, i.e. dust or a failing fan.
>

Some Thinkpads don't run the fan properly after a suspend+resume
when running OpenBSD.  It couldn't be that, could it?

123