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
Many recent disks have a 4KiB sector size, so newfs's default
2KiB frag size seems suboptimal for these drives. Newfs's man
page states: "The optimal block:fragment ratio is 8:1. Other
ratios are possible, but are not recommended, and may produce
poor results." (It is not clear to me what the 8:1
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
On Mon, 12 Dec 2011 17:10:46 +0100
Lars Engels wrote:
> Did you use -jX to build the world?
>
I'm top posting since Lars did.
It was buildkernel, not buildworld.
Yes, -j6.
> _
> Von: Gary Jennejohn
> Versendet am: Mon Dec 12 16:32:21 MEZ 2011
> An
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
Would it be possible to implement a mechanism that lets one change the
scheduler on the fly? Afaik Solaris can do that.
_
Von: Steve Kargl
Versendet am: Mon Dec 12 16:51:59 MEZ 2011
An: "O. Hartmann"
CC: freebsd-performance@freebsd.org, Current FreeBS
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-performance@freebsd.org
Betreff: Re: SCHED_ULE should n
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
20 matches
Mail list logo
