On 22/4/18 9:43 pm, Rick Macklem wrote:
Konstantin Belousov wrote:
On Sat, Apr 21, 2018 at 11:30:55PM +, Rick Macklem wrote:
Konstantin Belousov wrote:
On Sat, Apr 21, 2018 at 07:21:58PM +, Rick Macklem wrote:
I decided to start a new thread on current related to SCHED_ULE, since I se
On 22/4/18 10:36 pm, Rodney W. Grimes wrote:
Konstantin Belousov wrote:
On Sat, Apr 21, 2018 at 11:30:55PM +, Rick Macklem wrote:
Konstantin Belousov wrote:
On Sat, Apr 21, 2018 at 07:21:58PM +, Rick Macklem wrote:
I decided to start a new thread on current related to SCHED_ULE, since
On 22/4/18 10:36 pm, Rodney W. Grimes wrote:
Konstantin Belousov wrote:
On Sat, Apr 21, 2018 at 11:30:55PM +, Rick Macklem wrote:
Konstantin Belousov wrote:
On Sat, Apr 21, 2018 at 07:21:58PM +, Rick Macklem wrote:
I decided to start a new thread on current related to SCHED_ULE, since
> Konstantin Belousov wrote:
> >On Sat, Apr 21, 2018 at 11:30:55PM +, Rick Macklem wrote:
> >> Konstantin Belousov wrote:
> >> >On Sat, Apr 21, 2018 at 07:21:58PM +, Rick Macklem wrote:
> >> >> I decided to start a new thread on current related to SCHED_ULE, since
> >> >> I see
> >> >> mor
Konstantin Belousov wrote:
>On Sat, Apr 21, 2018 at 11:30:55PM +, Rick Macklem wrote:
>> Konstantin Belousov wrote:
>> >On Sat, Apr 21, 2018 at 07:21:58PM +, Rick Macklem wrote:
>> >> I decided to start a new thread on current related to SCHED_ULE, since I
>> >> see
>> >> more than just pe
On Sat, Apr 21, 2018 at 11:30:55PM +, Rick Macklem wrote:
> Konstantin Belousov wrote:
> >On Sat, Apr 21, 2018 at 07:21:58PM +, Rick Macklem wrote:
> >> I decided to start a new thread on current related to SCHED_ULE, since I
> >> see
> >> more than just performance degradation and on a re
> On Sat, Apr 21, 2018 at 07:21:58PM +, Rick Macklem wrote:
> > I decided to start a new thread on current related to SCHED_ULE, since I see
> > more than just performance degradation and on a recent current kernel.
> > (I cc'd a couple of the people discussing performance problems in
> > free
Konstantin Belousov wrote:
>On Sat, Apr 21, 2018 at 07:21:58PM +, Rick Macklem wrote:
>> I decided to start a new thread on current related to SCHED_ULE, since I see
>> more than just performance degradation and on a recent current kernel.
>> (I cc'd a couple of the people discussing performanc
On Sat, Apr 21, 2018 at 07:21:58PM +, Rick Macklem wrote:
> I decided to start a new thread on current related to SCHED_ULE, since I see
> more than just performance degradation and on a recent current kernel.
> (I cc'd a couple of the people discussing performance problems in
> freebsd-stable
On 16.01.2014 11:20, Alexander wrote:
>
>
> 14.01.2014, 22:32, "Alexander" :
>> 14.01.2014, 20:14, "Subbsd" :
>>
>>> On Tue, Jan 14, 2014 at 7:43 PM, Andrey Chernov wrote:
On 14.01.2014 17:01, Alexander wrote:
> on Freebsd 9.2 x64 on 5 different PCs I installed net-p2p/cpuminer
>>>
Hello, Lev.
You wrote 12 января 2012 г., 15:00:20:
>> But what mav says makes sense.
> It is it -- stack size. Setting KSTACK_PAGES=6 fixes situation.
OOOPS. Not. After another 5 minutes ng_queue again consumes 100% CPU
:(
--
// Black Lion AKA Lev Serebryakov
___
Hello, Andriy.
You wrote 12 января 2012 г., 14:29:57:
> But what mav says makes sense.
It is it -- stack size. Setting KSTACK_PAGES=6 fixes situation.
Feature request: warn user when ng_queue is used due to stack
limitations :) I know from mav, that sometime it is unavoidable (with
protocols
Hello, Andriy.
You wrote 12 января 2012 г., 14:29:57:
> Well, I mostly meant things like uptime, load level and pattern, etc.
These are identical too -- freshly boot system, same load (torrent
client on other box), only load -- traffic, as it is router, same
upload/download speeds and peer cou
on 12/01/2012 12:05 Lev Serebryakov said the following:
> Hello, Andriy.
> You wrote 12 января 2012 г., 13:54:41:
>
>>> Switching to 4BSD helps. 4BSD works as usual: all CPU time is
>>> interrupts and network thread, system is responsive under heaviest load,
>>> normal operations of DNS, DHCP a
Hello, Andriy.
You wrote 12 января 2012 г., 13:54:41:
>> Switching to 4BSD helps. 4BSD works as usual: all CPU time is
>> interrupts and network thread, system is responsive under heaviest load,
>> normal operations of DNS, DHCP and hostapd.
> How reproducible is this result?
100%
> In other
on 12/01/2012 11:31 Lev Serebryakov said the following:
> Switching to 4BSD helps. 4BSD works as usual: all CPU time is
> interrupts and network thread, system is responsive under heaviest load,
> normal operations of DNS, DHCP and hostapd.
How reproducible is this result?
In other words, have
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 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 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 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, 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 stucks in the middle by ~1
> > second. When I switch back to SHED_4
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
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
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 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 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
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
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
Am 12/15/11 15:20, schrieb Steven Hartland:
> With all the discussion I thought I'd give a buildworld
> benchmark a go here on a spare 24 core machine. ULE
> tested fine but with 4BSD it wont even boot panicing
> with the following:-
> http://screensnapr.com/v/hwysGV.png
>
> This is on a clean 8.2
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
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/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
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
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
В 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 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 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
В 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
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 problems - it means the
>> > problem has Core2Duo, or in a piece of cod
В 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 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.
> ___
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 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 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 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 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
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-performa...@freebsd.org
> Betreff: Re: SCHED_ULE should not be the default
>
>
> On Mon, 12 Dec 2011 15:13:00 +
> Vincent
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
В 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
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
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
Did you use -jX to build the world?
_
Von: Gary Jennejohn
Versendet am: Mon Dec 12 16:32:21 MEZ 2011
An: Vincent Hoffman
CC: "O. Hartmann" , Current FreeBSD
, freebsd-sta...@freebsd.org,
freebsd-performa...@freebsd.org
Betreff: Re: SCHED_
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 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
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
-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
On Thursday 09 October 2003 10:00 pm, Evan Dower wrote:
> Is nvidia.ko still loaded in the kernel?
No it isn't. In fact, I completely deinstalled it and had a reboot since
then.
--
Jonathan Fosburgh
AIX and Storage Administrator
UT MD Anderson Cancer Center
Houston, TX
___
Il Ven, 2003-10-10 alle 04:54, Jonathan E Fosburgh ha scritto:
> On Thursday 09 October 2003 08:16 pm, Evan Dower wrote:
> > How many of the people experiencing SCHED_ULE related problems (primarily
> > lagging) are also using nvidia-driver? I know I am, and I'm pretty sure
> > Arjan is. Could ther
Hi !
I have a Matrox G550.
No DRI or other specials.
PS/2 mouse.
No moused.
UP machine.
The mouse stutters under compilation load
(in X).
I'll give moused a try and look whether
the behaviour is the same on the console,
but I doubt it.
I suspect this thing is rendering related.
Cheers
Peter
--
Evan Dower wrote:
How many of the people experiencing SCHED_ULE related problems
(primarily lagging) are also using nvidia-driver? I know I am, and I'm
pretty sure Arjan is. Could there be a connection?
No, I have an ATI Radeon now. The problem seems to appear independently
of the video driver
From: Jonathan E Fosburgh <[EMAIL PROTECTED]>
I switched back to the XFree86 nv driver earlier today and still have
trouble.
moused is running and it is a PS/2 mouse.
Is nvidia.ko still loaded in the kernel?
--
Evan Dower
Undergraduate, Computer Science
University of Washington
Public key: http:
On Thursday 09 October 2003 08:16 pm, Evan Dower wrote:
> How many of the people experiencing SCHED_ULE related problems (primarily
> lagging) are also using nvidia-driver? I know I am, and I'm pretty sure
> Arjan is. Could there be a connection?
I switched back to the XFree86 nv driver earlier to
http://students.washington.edu/evantd/pgp-pub-key.txt
Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D
From: Arjan van Leeuwen <[EMAIL PROTECTED]>
To: Jeff Roberson <[EMAIL PROTECTED]>,Sheldon Hearn
<[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: Sched_Ule
Date: Thu, 9
On Thu, 9 Oct 2003, Jeff Roberson wrote:
> >
> > 1) Use a USB mouse, not a PS2 mouse.
>
> Is this _only_ with usb?
Is moused running?
That would give an extra scheduling complication..
>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/m
On Thursday 09 October 2003 22:57, Jeff Roberson wrote:
> On Thu, 9 Oct 2003, Sheldon Hearn wrote:
> > On (2003/10/09 00:28), Scott Sipe wrote:
> > > Anything that seems disk intensive: bzip2 (unbzip2ing one big file
> > > makes this happen), making world, building ports, etc makes my X
> > > envir
On (2003/10/09 16:57), Jeff Roberson wrote:
> > For me, the sluggish mouse problem manifests under these conditions:
> >
> > 1) Use a USB mouse, not a PS2 mouse.
>
> Is this _only_ with usb?
For me, yes. -CURRENT gets a little sluggish with either scheduler, but
the noticible difference between
On Thu, 9 Oct 2003, Sheldon Hearn wrote:
> On (2003/10/09 00:28), Scott Sipe wrote:
>
> > Anything that seems disk intensive: bzip2 (unbzip2ing one big file makes
> > this happen), making world, building ports, etc makes my X environment
> > practically unusable. Mouse stutters, reaction times is
On (2003/10/09 00:28), Scott Sipe wrote:
> Anything that seems disk intensive: bzip2 (unbzip2ing one big file makes
> this happen), making world, building ports, etc makes my X environment
> practically unusable. Mouse stutters, reaction times is very slow, feels
> 10x more sluggish than normal.
AIL PROTECTED]>
To: Evan Dower <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], <[EMAIL PROTECTED]>
Subject: Re: Sched_Ule
Date: Thu, 9 Oct 2003 10:33:39 -0400 (EDT)
On Thu, 9 Oct 2003, Evan Dower wrote:
> I ran with SCHED_ULE for a couple days recently and had trouble beyond
just
>
On Thu, 9 Oct 2003, Evan Dower wrote:
> I ran with SCHED_ULE for a couple days recently and had trouble beyond just
> sluggishness. When doing really intensive tasks such as buildworld or
> installworld, the computer would actually stall. The first time was
> immediately after booting single user
On Wednesday 08 October 2003 11:28 pm, Scott Sipe wrote:
> Anything that seems disk intensive: bzip2 (unbzip2ing one big file makes
> this happen), making world, building ports, etc makes my X environment
> practically unusable. Mouse stutters, reaction times is very slow, feels
> 10x more sluggi
I ran with SCHED_ULE for a couple days recently and had trouble beyond just
sluggishness. When doing really intensive tasks such as buildworld or
installworld, the computer would actually stall. The first time was
immediately after booting single user after building the world and kernel. I
star
On Fri, 7 Mar 2003, Kris Kennaway wrote:
> On Fri, Mar 07, 2003 at 09:41:07AM +0200, Vallo Kallaste wrote:
> > Althought much better, KDE is still almost unusable, XFree and KDE
> > startup takes a lot more time and starting plain xterm under KDE
> > takes x3 time than usual. When I kill one of th
On Fri, Mar 07, 2003 at 08:57:01AM -0800, Kris Kennaway
<[EMAIL PROTECTED]> wrote:
> As noted in Jeff's original mail, niced processes do not behave nicely
> yet.
Yes, I'm sorry that slipped off my first reading. Otherwise, the new
scheduler is very useable for me. Thanks for pointing out, Kris.
On Fri, Mar 07, 2003 at 09:41:07AM +0200, Vallo Kallaste wrote:
> > > All interactive tasks are very responsive. My nice -5'd looping process
> > > is getting 70% of the cpu and my compile is taking the rest. nice +20 may
> > > not behave as well as in sched_4bsd right now. I'm going to work on
1 - 100 of 110 matches
Mail list logo
