[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject: Re: 2.4.4 sluggish under fork load
>The fact that 2.4.4 gives the whole timeslice to the child
>is just bogus to begin with.
I only did that because I could not find another way
to make the child ru
> OK I found the explanation now. The reason ksoftirqd was deadlocking on
> me without the explicit clear of SCHED_YIELD in p->policy is because a
> softirq event was pending at the time of the first kernel_thread() and
> then while returning from the syscall it was so taking the ret_from_irq
Oh
On 05.01 Andrea Arcangeli wrote:
>
> And if you fork off a child with its p->policy SCHED_YIELD set it will
> never get scheduled in.
>
> Only "just" running tasks can have SCHED_YIELD set.
>
> So the below lines are the *right* and most robust approch as far I can
> tell. (plus counter needs
On Tue, May 01, 2001 at 07:18:49AM +0200, Andrea Arcangeli wrote:
> I'm running with this below patch applied since a some time (I didn't
> submitted it because for some reason unless I do p->policy &=
> ~SCHED_YIELD ksoftirqd deadlocks at boot and I didn't yet investigated
> why, and I'd like to
On Mon, Apr 30, 2001 at 11:38:23PM -0300, Rik van Riel wrote:
> On Mon, 30 Apr 2001, Andrea Arcangeli wrote:
> > On Sun, Apr 29, 2001 at 10:26:57AM +0200, Peter Osterlund wrote:
>
> > > - p->counter = current->counter;
> > > - current->counter = 0;
> > > + p->counter = (current->counter + 1) >> 1
>The fact that 2.4.4 gives the whole timeslice to the child
>is just bogus to begin with.
I only did that because I could not find another way
to make the child run first that worked in practice. I tried
other things before that. Since Peter Osterlund's SCHED_YIELD
thing works, we no lo
On Mon, 30 Apr 2001, Andrea Arcangeli wrote:
> On Sun, Apr 29, 2001 at 10:26:57AM +0200, Peter Osterlund wrote:
> > - p->counter = current->counter;
> > - current->counter = 0;
> > + p->counter = (current->counter + 1) >> 1;
> > + current->counter >>= 1;
> > + current->policy |= SCHED_Y
On Mon, 30 Apr 2001, Andrea Arcangeli wrote:
> please try to reproduce the bad behaviour with 2.4.4aa2. There's a bug
> in the parent-timeslice patch in 2.4 that I fixed while backporting it
> to 2.2aa and that I now forward ported the fix to 2.4aa. The fact
> 2.4.4 gives the whole timeslice to t
On Sun, Apr 29, 2001 at 10:26:57AM +0200, Peter Osterlund wrote:
> On Sat, 28 Apr 2001, Linus Torvalds wrote:
>
> > > could we leave it at half, but set the parent to SCHED_YIELD?
> >
> > Sounds like a good idea. Peter, how does that feel to you? I bet that I'v
> > enever seen it simply because a
On Sat, 28 Apr 2001, Linus Torvalds wrote:
> > could we leave it at half, but set the parent to SCHED_YIELD?
>
> Sounds like a good idea. Peter, how does that feel to you? I bet that I'v
> enever seen it simply because all my machines are (a) much too powerful
> for any reasonable use and (b) SMP
On rereading Linus's message, I see that he indicated that
"while true ; do /bin/true ; done" was known to be a bash bug, not
just a suggested possibility. Sorry for acting as if this were
a new discovery. Anyhow, I hope that at least the proposed bash
patch that I submitted may be of so
Peter Osterlund wrote:
> Another thing is that the bash loop "while true ; do /bin/true ; done" is
> not possible to interrupt with ctrl-c.
I have reproduced this on a uniprocessor machine and determined
that it is a bash bug. I will submit a bash bug report and sample
patch that fixes t
Peter Osterlund wrote:
>
> I have noticed that 2.4.4 feels a lot less responsive than 2.4.3 under
> fork load. This is caused by the "run child first after fork" patch. I
> have tested on two different UP x86 systems running redhat 7.0.
>
> For example, when running the gcc configure script, the
On Sat, 28 Apr 2001, Linus Torvalds wrote:
> > Reverting the fork patch makes all these problems go away on my machine.
>
> Reverting it outright may be an acceptable approach. I'll think about
> it: the arguments _for_ the patch are true and real, and it shows up as
> real improvements on some t
John Kacur <[EMAIL PROTECTED]> writes:
> >Peter Osterlund wrote:
> >>
> >> Another thing is that the bash loop "while true ; do /bin/true ; done" is
> >> not possible to interrupt with ctrl-c.
>
> >Same thing here.
>
> I'm not having any problems. Just a quick question, is everyone who
On Sat, 28 Apr 2001, Peter Osterlund wrote:
>
> For example, when running the gcc configure script, the X mouse pointer is
> very jerky. The configure script itself runs approximately as fast as in
> 2.4.3.
Ok. Fair enough. The new "run the child first" approach has advantages,
but it is entire
>Peter Osterlund wrote:
>>
>> Another thing is that the bash loop "while true ; do /bin/true ; done" is
>> not possible to interrupt with ctrl-c.
>Same thing here.
I'm not having any problems. Just a quick question, is everyone who is
having a problem running with more than one cpu?
Jo
Peter Osterlund wrote:
>
> Another thing is that the bash loop "while true ; do /bin/true ; done" is
> not possible to interrupt with ctrl-c.
Same thing here.
> A third thing I noticed is that starting a gnome session in redhat 7.0
> takes longer. (It takes more time for the gnome splas
Peter Osterlund wrote:
>
> I have noticed that 2.4.4 feels a lot less responsive than 2.4.3 under
> fork load. This is caused by the "run child first after fork" patch. I
> have tested on two different UP x86 systems running redhat 7.0.
>
> For example, when running the gcc configure script, the
On 04.28 Peter Osterlund wrote:
>
> Another thing is that the bash loop "while true ; do /bin/true ; done" is
> not possible to interrupt with ctrl-c.
>
Just tried that under 2.4.4 on two terminals at the same time and the system
even noticed it. Both cpus were running at about 45%user+55%sys,
20 matches
Mail list logo
