Rik van Riel wrote:
>
> On Thu, 12 Apr 2001, Pavel Machek wrote:
>
> > > One rule of optimization is to move any code you can outside the loop.
> > > Why isn't the nice_to_ticks calculation done when nice is changed
> > > instead of EVERY recalc.? I guess another way to ask this is, who needs
>
On Thu, 12 Apr 2001, Pavel Machek wrote:
> > One rule of optimization is to move any code you can outside the loop.
> > Why isn't the nice_to_ticks calculation done when nice is changed
> > instead of EVERY recalc.? I guess another way to ask this is, who needs
>
> This way change is localized
Hi!
> One rule of optimization is to move any code you can outside the loop.
> Why isn't the nice_to_ticks calculation done when nice is changed
> instead of EVERY recalc.? I guess another way to ask this is, who needs
This way change is localized very nicely, and it is "obviously right".
--
On Wed, Apr 11, 2001 at 12:53:16PM -0300, Rik van Riel wrote:
> On Wed, 11 Apr 2001, Rik van Riel wrote:
>
> > OK, here it is. It's nothing like montavista's singing-dancing
> > scheduler patch that does all, just a really minimal change that
> > should stretch the nice levels to yield the follow
One rule of optimization is to move any code you can outside the loop.
Why isn't the nice_to_ticks calculation done when nice is changed
instead of EVERY recalc.? I guess another way to ask this is, who needs
to see the original nice? Would it be worth another task_struct entry
to move this cal
On Wed, 11 Apr 2001, Rik van Riel wrote:
> OK, here it is. It's nothing like montavista's singing-dancing
> scheduler patch that does all, just a really minimal change that
> should stretch the nice levels to yield the following CPU usage:
>
> Nice05 10 15 19
> %CPU 100 56 25
On Tue, 10 Apr 2001, Rik van Riel wrote:
> I'll try to come up with a recalculation change that will make
> this thing behave better, while still retaining the short time
> slices for multiple normal-priority tasks and the cache footprint
> schedule() and friends currently have...
OK, here it is
Rik van Riel wrote:
>
> On Mon, 9 Apr 2001, george anzinger wrote:
> > SodaPop wrote:
> > >
> > > I too have noticed that nicing processes does not work nearly as
> > > effectively as I'd like it to. I run on an underpowered machine,
> > > and have had to stop running things such as seti because
On Mon, 9 Apr 2001, george anzinger wrote:
> SodaPop wrote:
> >
> > I too have noticed that nicing processes does not work nearly as
> > effectively as I'd like it to. I run on an underpowered machine,
> > and have had to stop running things such as seti because it steals too
> > much cpu time,
SodaPop wrote:
>
> I too have noticed that nicing processes does not work nearly as
> effectively as I'd like it to. I run on an underpowered machine,
> and have had to stop running things such as seti because it steals too
> much cpu time, even when maximally niced.
>
> As an example, I can ru
LA Walsh <[EMAIL PROTECTED]> writes:
> I was running 2 copies of setiathome on a 4 CPU server
>@ work. The two processes ran nice'd -19. The builds we were
>running still took 20-30% longer as opposed to when setiathome wasn't
>running (went from 45 minutes up to about an hour). This mac
I too have noticed that nicing processes does not work nearly as
effectively as I'd like it to. I run on an underpowered machine,
and have had to stop running things such as seti because it steals too
much cpu time, even when maximally niced.
As an example, I can run mpg123 and a kernel build co
Quim K Holland wrote:
>
> > "BS" == BERECZ Szabolcs <[EMAIL PROTECTED]> writes:
>
> BS> ... a setiathome running at nice level 19, and a bladeenc at
> BS> nice level 0. setiathome uses 14 percent, and bladeenc uses
> BS> 84 percent of the processor. I think, setiathome should use
> BS> max 2
> "BS" == BERECZ Szabolcs <[EMAIL PROTECTED]> writes:
BS> ... a setiathome running at nice level 19, and a bladeenc at
BS> nice level 0. setiathome uses 14 percent, and bladeenc uses
BS> 84 percent of the processor. I think, setiathome should use
BS> max 2-3 percent. the 14 percent is way to
Hi!
I just noticed, that a process with nice level 19, gets some processor
time, even if there is another process, which would use all of the
processor time.
for example, there is a setiathome running at nice level 19, and a
bladeenc at nice level 0. setiathome uses 14 percent, and bladeenc uses
15 matches
Mail list logo
