On Mon, 19 Dec 2011 23:22:40 +0200
Andriy Gapon wrote:
> on 19/12/2011 17:50 Nathan Whitehorn said the following:
> > The thing I've seen is that ULE is substantially more enthusiastic about
> > migrating processes between cores than 4BSD.
>
> Hmm, this seems to be contrary to my theoretical exp
on 19/12/2011 17:50 Nathan Whitehorn said the following:
> The thing I've seen is that ULE is substantially more enthusiastic about
> migrating processes between cores than 4BSD.
Hmm, this seems to be contrary to my theoretical expectations. I thought that
with 4BSD all threads that were not in o
On Mon Dec 19 11, Nathan Whitehorn wrote:
> On 12/18/11 04:34, Adrian Chadd wrote:
> >The trouble is that there's lots of anecdotal evidence, but noone's
> >really gone digging deep into _their_ example of why it's broken. The
> >developers who know this stuff don't see anything wrong. That hints t
On 12/18/11 04:34, Adrian Chadd wrote:
The trouble is that there's lots of anecdotal evidence, but noone's
really gone digging deep into _their_ example of why it's broken. The
developers who know this stuff don't see anything wrong. That hints to
me it may be something a little more creepy - as
The trouble is that there's lots of anecdotal evidence, but noone's
really gone digging deep into _their_ example of why it's broken. The
developers who know this stuff don't see anything wrong. That hints to
me it may be something a little more creepy - as an example, the
interplay between netisr/
On Sun Dec 18 11, Alexander Best wrote:
> On Sun Dec 18 11, Andrey Chernov wrote:
> > On Sun, Dec 18, 2011 at 05:51:47PM +1100, Ian Smith wrote:
> > > On Sun, 18 Dec 2011 02:37:52 +, Bruce Cran wrote:
> > > > On 13/12/2011 09:00, Andrey Chernov wrote:
> > > > > I observe ULE interactivity slo
On Sun Dec 18 11, Andrey Chernov wrote:
> On Sun, Dec 18, 2011 at 05:51:47PM +1100, Ian Smith wrote:
> > On Sun, 18 Dec 2011 02:37:52 +, Bruce Cran wrote:
> > > On 13/12/2011 09:00, Andrey Chernov wrote:
> > > > I observe ULE interactivity slowness even on single core machine
> > (Pentium
>
On Thu, Dec 15, 2011 at 9:58 PM, Mike Tancsa wrote:
> On 12/15/2011 11:56 AM, Attilio Rao wrote:
>> So, as very first thing, can you try the following:
>> - Same codebase, etc. etc.
>> - Make the test 4 times, discard the first and ministat for the other 3
>> - Reboot
>> - Change the steal_thresh
On Thu, Dec 15, 2011 at 05:26:27PM +0100, Attilio Rao wrote:
> 2011/12/13 Jeremy Chadwick :
> > On Mon, Dec 12, 2011 at 02:47:57PM +0100, O. Hartmann wrote:
> >> > Not fully right, boinc defaults to run on idprio 31 so this isn't an
> >> > issue. And yes, there are cases where SCHED_ULE shows much
Hi,
What Attilllo and others need are KTR traces in the most stripped down
example of interactive-busting workload you can find.
Eg: if you're doing 32 concurrent buildworlds and trying to test
interactivity - fine, but that's going to result in a lot of KTR
stuff.
If you can reproduce it using a
On 12/18/11 03:37, Bruce Cran wrote:
> On 13/12/2011 09:00, Andrey Chernov wrote:
>> I observe ULE interactivity slowness even on single core machine
>> (Pentium 4) in very visible places, like 'ps ax' output stucks in the
>> middle by ~1 second. When I switch back to SHED_4BSD, all slowness is
>>
On 18/12/2011 10:34, Adrian Chadd wrote:
I applaud reppie for trying to make it as easy as possible for people
to use KTR to provide scheduler traces for him to go digging with, so
please, if you have these issues and you can absolutely reproduce
them, please follow his instructions and work with
On Sun, Dec 18, 2011 at 05:51:47PM +1100, Ian Smith wrote:
> On Sun, 18 Dec 2011 02:37:52 +, Bruce Cran wrote:
> > On 13/12/2011 09:00, Andrey Chernov wrote:
> > > I observe ULE interactivity slowness even on single core machine (Pentium
> > > 4) in very visible places, like 'ps ax' output s
On 13/12/2011 09:00, Andrey Chernov wrote:
I observe ULE interactivity slowness even on single core machine
(Pentium 4) in very visible places, like 'ps ax' output stucks in the
middle by ~1 second. When I switch back to SHED_4BSD, all slowness is
gone.
I'm also seeing problems with ULE on a
2011/12/15 Mike Tancsa :
> On 12/15/2011 11:56 AM, Attilio Rao wrote:
>> So, as very first thing, can you try the following:
>> - Same codebase, etc. etc.
>> - Make the test 4 times, discard the first and ministat for the other 3
>> - Reboot
>> - Change the steal_thresh value
>> - Make the test 4 t
On 12/15/2011 11:56 AM, Attilio Rao wrote:
> So, as very first thing, can you try the following:
> - Same codebase, etc. etc.
> - Make the test 4 times, discard the first and ministat for the other 3
> - Reboot
> - Change the steal_thresh value
> - Make the test 4 times, discard the first and minis
В Thu, 15 Dec 2011 20:02:44 +0100
Attilio Rao пишет:
> 2011/12/15 Jeremy Chadwick :
> > On Thu, Dec 15, 2011 at 05:26:27PM +0100, Attilio Rao wrote:
> >> 2011/12/13 Jeremy Chadwick :
> >> > On Mon, Dec 12, 2011 at 02:47:57PM +0100, O. Hartmann wrote:
> >> >> > Not fully right, boinc defaults to r
2011/12/15 Jeremy Chadwick :
> On Thu, Dec 15, 2011 at 05:26:27PM +0100, Attilio Rao wrote:
>> 2011/12/13 Jeremy Chadwick :
>> > On Mon, Dec 12, 2011 at 02:47:57PM +0100, O. Hartmann wrote:
>> >> > Not fully right, boinc defaults to run on idprio 31 so this isn't an
>> >> > issue. And yes, there ar
2011/12/15 Mike Tancsa :
> On 12/15/2011 11:42 AM, Attilio Rao wrote:
>>
>> I'm thinking now to a better test-case for this: can you try that on a
>> tmpfs volume?
>
> There is enough RAM in the box so that it should not touch the disk, and
> I was sending the output to /dev/null, so it was not wri
2011/12/13 Jeremy Chadwick :
> On Mon, Dec 12, 2011 at 02:47:57PM +0100, O. Hartmann wrote:
>> > Not fully right, boinc defaults to run on idprio 31 so this isn't an
>> > issue. And yes, there are cases where SCHED_ULE shows much better
>> > performance then SCHED_4BSD. [...]
>>
>> Do we have any
On 12/15/2011 11:42 AM, Attilio Rao wrote:
>
> I'm thinking now to a better test-case for this: can you try that on a
> tmpfs volume?
There is enough RAM in the box so that it should not touch the disk, and
I was sending the output to /dev/null, so it was not writing to the disk.
>
> Also what
2011/12/14 Mike Tancsa :
> On 12/13/2011 7:01 PM, m...@freebsd.org wrote:
>>
>> Has anyone experiencing problems tried to set sysctl
>> kern.sched.steal_thresh=1 ?
>>
>> I don't remember what our specific problem at $WORK was, perhaps it
>> was just interrupt threads not getting serviced fast enou
2011/12/15 Mike Tancsa :
> On 12/15/2011 11:26 AM, Attilio Rao wrote:
>>
>> Hi Mike,
>> was that just the same codebase with the switch SCHED_4BSD/SCHED_ULE?
>
> Hi Attilio,
> It was the same codebase.
>
>
>> Could you retry the bench checking CPU usage and possible thread
>> migration aroun
On 12/15/2011 11:26 AM, Attilio Rao wrote:
>
> Hi Mike,
> was that just the same codebase with the switch SCHED_4BSD/SCHED_ULE?
Hi Attilio,
It was the same codebase.
> Could you retry the bench checking CPU usage and possible thread
> migration around for both cases?
I can, but how do
On Tue, Dec 13, 2011 at 02:22:48AM -0800, Adrian Chadd wrote:
> On 13 December 2011 01:00, Andrey Chernov wrote:
>
> >> If the algorithm ULE does not contain problems - it means the problem
> >> has Core2Duo, or in a piece of code that uses the ULE scheduler.
> >
> > I observe ULE interactivity s
On Mon, Dec 12, 2011 at 04:29:14PM -0800, Doug Barton wrote:
> On 12/12/2011 05:47, O. Hartmann wrote:
> > Do we have any proof at hand for such cases where SCHED_ULE performs
> > much better than SCHED_4BSD?
>
> I complained about poor interactive performance of ULE in a desktop
> environment for
On Tue, Dec 13, 2011 at 10:40:48AM +0200, Ivan Klymenko wrote:
> If the algorithm ULE does not contain problems - it means the problem
> has Core2Duo, or in a piece of code that uses the ULE scheduler.
> I already wrote in a mailing list that specifically in my case (Core2Duo)
> partially helps the
On 12/13/2011 13:31, Malin Randstrom wrote:
> stop sending me spam mail ... you never stop despite me having unsubscribeb
> several times. stop this!
If you had actually unsubscribed, the mail would have stopped. :)
You can see the instructions you need to follow below.
> ___
stop sending me spam mail ... you never stop despite me having unsubscribeb
several times. stop this!
On Dec 13, 2011 8:12 PM, "Steve Kargl"
wrote:
> On Tue, Dec 13, 2011 at 02:23:46PM +0100, O. Hartmann wrote:
> > On 12/12/11 16:51, Steve Kargl wrote:
> > > On Mon, Dec 12, 2011 at 02:47:57PM +01
В Wed, 14 Dec 2011 21:34:35 +0400
Andrey Chernov пишет:
> On Tue, Dec 13, 2011 at 02:22:48AM -0800, Adrian Chadd wrote:
> > On 13 December 2011 01:00, Andrey Chernov wrote:
> >
> > >> If the algorithm ULE does not contain problems - it means the
> > >> problem has Core2Duo, or in a piece of cod
On 12/13/2011 7:01 PM, m...@freebsd.org wrote:
>
> Has anyone experiencing problems tried to set sysctl
> kern.sched.steal_thresh=1 ?
>
> I don't remember what our specific problem at $WORK was, perhaps it
> was just interrupt threads not getting serviced fast enough, but we've
> hard-coded this
On Wed, 14 Dec 2011, Ivan Klymenko wrote:
?? Wed, 14 Dec 2011 00:04:42 +0100
Jilles Tjoelker ??:
On Tue, Dec 13, 2011 at 10:40:48AM +0200, Ivan Klymenko wrote:
If the algorithm ULE does not contain problems - it means the
problem has Core2Duo, or in a piece of code that uses the ULE
В Tue, 13 Dec 2011 16:01:56 -0800
m...@freebsd.org пишет:
> On Tue, Dec 13, 2011 at 3:39 PM, Ivan Klymenko wrote:
> > В Wed, 14 Dec 2011 00:04:42 +0100
> > Jilles Tjoelker пишет:
> >
> >> On Tue, Dec 13, 2011 at 10:40:48AM +0200, Ivan Klymenko wrote:
> >> > If the algorithm ULE does not contain
В Tue, 13 Dec 2011 23:02:15 +
Marcus Reid пишет:
> On Mon, Dec 12, 2011 at 04:29:14PM -0800, Doug Barton wrote:
> > On 12/12/2011 05:47, O. Hartmann wrote:
> > > Do we have any proof at hand for such cases where SCHED_ULE
> > > performs much better than SCHED_4BSD?
> >
> > I complained about
В Wed, 14 Dec 2011 00:04:42 +0100
Jilles Tjoelker пишет:
> On Tue, Dec 13, 2011 at 10:40:48AM +0200, Ivan Klymenko wrote:
> > If the algorithm ULE does not contain problems - it means the
> > problem has Core2Duo, or in a piece of code that uses the ULE
> > scheduler. I already wrote in a mailing
On 12/13/2011 10:54 AM, Steve Kargl wrote:
>
> I have given the WHY in previous discussions of ULE, based
> on what you call legacy benchmarks. I have not seen any
> commit to sched_ule.c that would lead me to believe that
> the performance issues with ULE and cpu-bound numerical
> codes have bee
On Tue, Dec 13, 2011 at 02:23:46PM +0100, O. Hartmann wrote:
> On 12/12/11 16:51, Steve Kargl wrote:
> > On Mon, Dec 12, 2011 at 02:47:57PM +0100, O. Hartmann wrote:
> >>
> >>> Not fully right, boinc defaults to run on idprio 31 so this isn't an
> >>> issue. And yes, there are cases where SCHED_ULE
On 12/12/11 16:51, Steve Kargl wrote:
> On Mon, Dec 12, 2011 at 02:47:57PM +0100, O. Hartmann wrote:
>>
>>> Not fully right, boinc defaults to run on idprio 31 so this isn't an
>>> issue. And yes, there are cases where SCHED_ULE shows much better
>>> performance then SCHED_4BSD. [...]
>>
>> Do we
On Tue, Dec 13, 2011 at 12:13:42PM +0100, O. Hartmann wrote:
> On 12/12/11 16:13, Vincent Hoffman wrote:
> >
> > On 12/12/2011 13:47, O. Hartmann wrote:
> >
> >>> Not fully right, boinc defaults to run on idprio 31 so this isn't an
> >>> issue. And yes, there are cases where SCHED_ULE shows much
On 12/12/11 16:13, Vincent Hoffman wrote:
>
> On 12/12/2011 13:47, O. Hartmann wrote:
>
>>> Not fully right, boinc defaults to run on idprio 31 so this isn't an
>>> issue. And yes, there are cases where SCHED_ULE shows much better
>>> performance then SCHED_4BSD. [...]
>
>> Do we have any proof
On Tue, Dec 13, 2011 at 10:40:48AM +0200, Ivan Klymenko wrote:
> > On 12/12/2011 05:47, O. Hartmann wrote:
> > > Do we have any proof at hand for such cases where SCHED_ULE performs
> > > much better than SCHED_4BSD?
> >
> > I complained about poor interactive performance of ULE in a desktop
> > e
On Mon, Dec 12, 2011 at 02:47:57PM +0100, O. Hartmann wrote:
> > Not fully right, boinc defaults to run on idprio 31 so this isn't an
> > issue. And yes, there are cases where SCHED_ULE shows much better
> > performance then SCHED_4BSD. [...]
>
> Do we have any proof at hand for such cases where
On 13 December 2011 01:00, Andrey Chernov wrote:
>> If the algorithm ULE does not contain problems - it means the problem
>> has Core2Duo, or in a piece of code that uses the ULE scheduler.
>
> I observe ULE interactivity slowness even on single core machine (Pentium
> 4) in very visible places,
> On 12/12/2011 05:47, O. Hartmann wrote:
> > Do we have any proof at hand for such cases where SCHED_ULE performs
> > much better than SCHED_4BSD?
>
> I complained about poor interactive performance of ULE in a desktop
> environment for years. I had numerous people try to help, including
> Jeff,
On 12/12/2011 05:47, O. Hartmann wrote:
> Do we have any proof at hand for such cases where SCHED_ULE performs
> much better than SCHED_4BSD?
I complained about poor interactive performance of ULE in a desktop
environment for years. I had numerous people try to help, including
Jeff, with various t
On 12/12/2011 23:48, O. Hartmann wrote:
Is the tuning of kern.sched.preempt_thresh and a proper method of
estimating its correct value for the intended to use workload
documented in the manpages, maybe tuning()? I find it hard to crawl a
lot of pros and cons of mailing lists for evaluating a co
On 12/12/11 18:06, Steve Kargl wrote:
> On Mon, Dec 12, 2011 at 04:18:35PM +, Bruce Cran wrote:
>> On 12/12/2011 15:51, Steve Kargl wrote:
>>> This comes up every 9 months or so, and must be approaching FAQ
>>> status. In a HPC environment, I recommend 4BSD. Depending on the
>>> workload, ULE
On Mon, Dec 12, 2011 at 01:03:30PM -0600, Scott Lambert wrote:
> On Mon, Dec 12, 2011 at 09:06:04AM -0800, Steve Kargl wrote:
> > Tuning kern.sched.preempt_thresh did not seem to help for
> > my workload. My code is a classic master-slave OpenMPI
> > application where the master runs on one node a
On Monday, December 12, 2011 12:06:04 pm Steve Kargl wrote:
> On Mon, Dec 12, 2011 at 04:18:35PM +, Bruce Cran wrote:
> > On 12/12/2011 15:51, Steve Kargl wrote:
> > >This comes up every 9 months or so, and must be approaching FAQ
> > >status. In a HPC environment, I recommend 4BSD. Depending
On Mon, Dec 12, 2011 at 04:18:35PM +, Bruce Cran wrote:
> On 12/12/2011 15:51, Steve Kargl wrote:
> >This comes up every 9 months or so, and must be approaching FAQ
> >status. In a HPC environment, I recommend 4BSD. Depending on the
> >workload, ULE can cause a severe increase in turn around
On Mon, 12 Dec 2011 08:04:37 -0800
m...@freebsd.org wrote:
> On Mon, Dec 12, 2011 at 7:32 AM, Gary Jennejohn
> wrote:
> > On Mon, 12 Dec 2011 15:13:00 +
> > Vincent Hoffman wrote:
> >
> >>
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> On 12/12/2011 13:47, O. Hartmann wrot
12 16:32:21 MEZ 2011
> An: Vincent Hoffman
> CC: "O. Hartmann" , Current FreeBSD
> , freebsd-sta...@freebsd.org,
> freebsd-performance@freebsd.org
> Betreff: Re: SCHED_ULE should not be the default
>
>
> On Mon, 12 Dec 2011 15:13:00 +
> Vincent
On Mon, Dec 12, 2011 at 7:32 AM, Gary Jennejohn
wrote:
> On Mon, 12 Dec 2011 15:13:00 +
> Vincent Hoffman wrote:
>
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 12/12/2011 13:47, O. Hartmann wrote:
>> >
>> >> Not fully right, boinc defaults to run on idprio 31 so this isn't
On Mon, Dec 12, 2011 at 09:06:04AM -0800, Steve Kargl wrote:
> Tuning kern.sched.preempt_thresh did not seem to help for
> my workload. My code is a classic master-slave OpenMPI
> application where the master runs on one node and all
> cpu-bound slaves are sent to a second node. If I send
> send
В Mon, 12 Dec 2011 16:18:35 +
Bruce Cran пишет:
> On 12/12/2011 15:51, Steve Kargl wrote:
> > This comes up every 9 months or so, and must be approaching FAQ
> > status. In a HPC environment, I recommend 4BSD. Depending on the
> > workload, ULE can cause a severe increase in turn around tim
g, Current FreeBSD
, freebsd-sta...@freebsd.org
Betreff: Re: SCHED_ULE should not be the default
On Mon, Dec 12, 2011 at 02:47:57PM +0100, O. Hartmann wrote:
>
> > Not fully right, boinc defaults to run on idprio 31 so this isn't an
> > issue. And yes, there are cases whe
ULE should not be the default
On Mon, 12 Dec 2011 15:13:00 +
Vincent Hoffman wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 12/12/2011 13:47, O. Hartmann wrote:
> >
> >> Not fully right, boinc defaults to run on idprio 31 so this isn't
On Mon, 12 Dec 2011 15:13:00 +
Vincent Hoffman wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 12/12/2011 13:47, O. Hartmann wrote:
> >
> >> Not fully right, boinc defaults to run on idprio 31 so this isn't an
> >> issue. And yes, there are cases where SCHED_ULE shows much
On Monday 12 December 2011 14:47:57 O. Hartmann wrote:
> > Not fully right, boinc defaults to run on idprio 31 so this isn't an
> > issue. And yes, there are cases where SCHED_ULE shows much better
> > performance then SCHED_4BSD. [...]
>
> Do we have any proof at hand for such cases where SCHED_U
On 12/12/2011 15:51, Steve Kargl wrote:
This comes up every 9 months or so, and must be approaching FAQ
status. In a HPC environment, I recommend 4BSD. Depending on the
workload, ULE can cause a severe increase in turn around time when
doing already long computations. If you have an MPI applica
On Mon, Dec 12, 2011 at 02:47:57PM +0100, O. Hartmann wrote:
>
> > Not fully right, boinc defaults to run on idprio 31 so this isn't an
> > issue. And yes, there are cases where SCHED_ULE shows much better
> > performance then SCHED_4BSD. [...]
>
> Do we have any proof at hand for such cases whe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/12/2011 13:47, O. Hartmann wrote:
>
>> Not fully right, boinc defaults to run on idprio 31 so this isn't an
>> issue. And yes, there are cases where SCHED_ULE shows much better
>> performance then SCHED_4BSD. [...]
>
> Do we have any proof at ha
> Not fully right, boinc defaults to run on idprio 31 so this isn't an
> issue. And yes, there are cases where SCHED_ULE shows much better
> performance then SCHED_4BSD. [...]
Do we have any proof at hand for such cases where SCHED_ULE performs
much better than SCHED_4BSD? Whenever the subject c
63 matches
Mail list logo
