[PATCH] O16.2int

[PATCH] O16.2int

[Con Kolivas]

[-- Attachment #1: Type: text/plain, Size: 18 bytes --]

Much simpler

Con

[-- Attachment #2: patch-O16.1-O16.2int --]
[-- Type: text/x-diff, Size: 2799 bytes --]

--- linux-2.6.0-test3-mm2-O16/kernel/sched.c	2003-08-16 17:38:49.000000000 +1000
+++ linux-2.6.0-test3-mm2-O16.2/kernel/sched.c	2003-08-16 17:38:28.000000000 +1000
@@ -143,6 +143,9 @@
 #define VARYING_CREDIT(p) \
 	(!(HIGH_CREDIT(p) || LOW_CREDIT(p)))
 
+#define TASK_PREEMPTS_CURR(p, rq) \
+	((p)->prio < (rq)->curr->prio)
+
 /*
  * BASE_TIMESLICE scales user-nice values [ -20 ... 19 ]
  * to time slice values.
@@ -463,24 +466,15 @@ static inline void activate_task(task_t 
 		 * of time they spend on the runqueue, waiting for execution
 		 * on a CPU, first time around:
 		 */
-		if (in_interrupt()){
+		if (in_interrupt())
 			p->activated = 2;
-			p->waker = p;
-		} else {
+		else
 		/*
 		 * Normal first-time wakeups get a credit too for on-runqueue
 		 * time, but it will be weighted down:
 		 */
 			p->activated = 1;
-			p->waker = current;
 		}
-	} else {
-		if (in_interrupt())
-			p->waker = p;
-		else
-			p->waker = current;
-	}
-
 	p->timestamp = now;
 
 	__activate_task(p, rq);
@@ -564,20 +558,6 @@ repeat:
 }
 #endif
 
-static inline int task_preempts_curr(task_t *p, runqueue_t *rq)
-{
-	if (p->prio < rq->curr->prio) {
-			/*
-			 * Prevent a task preempting it's own waker
-			 * to avoid starvation
-			 */
-			if (unlikely(rq->curr == p->waker))
-				return 0;
-			return 1;
-	}
-	return 0;
-}
-
 /***
  * try_to_wake_up - wake up a thread
  * @p: the to-be-woken-up thread
@@ -629,8 +609,9 @@ repeat_lock_task:
 				__activate_task(p, rq);
 			else {
 				activate_task(p, rq);
-				if (task_preempts_curr(p, rq))
-					resched_task(rq->curr);
+				if (TASK_PREEMPTS_CURR(p, rq) &&
+					(in_interrupt() || !p->mm))
+						resched_task(rq->curr);
 			}
 			success = 1;
 		}
@@ -684,7 +665,6 @@ void wake_up_forked_process(task_t * p)
 	p->sleep_avg = JIFFIES_TO_NS(CURRENT_BONUS(p) *
 		CHILD_PENALTY / 100 * MAX_SLEEP_AVG / MAX_BONUS);
 
-	p->waker = p->parent;
 	p->interactive_credit = 0;
 
 	p->prio = effective_prio(p);
@@ -1131,7 +1111,7 @@ static inline void pull_task(runqueue_t 
 	 * Note that idle threads have a prio of MAX_PRIO, for this test
 	 * to be always true for them.
 	 */
-	if (task_preempts_curr(p, this_rq))
+	if (TASK_PREEMPTS_CURR(p, this_rq))
 		set_need_resched();
 }
 
--- linux-2.6.0-test3-mm2-O16/include/linux/sched.h	2003-08-15 15:18:36.000000000 +1000
+++ linux-2.6.0-test3-mm2-O16.2/include/linux/sched.h	2003-08-16 17:39:20.000000000 +1000
@@ -378,7 +378,6 @@ struct task_struct {
 	 */
 	struct task_struct *real_parent; /* real parent process (when being debugged) */
 	struct task_struct *parent;	/* parent process */
-	struct task_struct *waker;	/* waker process */
 	struct list_head children;	/* list of my children */
 	struct list_head sibling;	/* linkage in my parent's children list */
 	struct task_struct *group_leader;

Re: [PATCH] O16.2int

[Wiktor Wodecki]

[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]

Hello Con,

On Sat, Aug 16, 2003 at 07:02:52PM +1000, Con Kolivas wrote:
> Much simpler
> 
> Con
[ snip ]

I just had a failure on of my raid1 devices (not related I think), the
system goes on in degregated mode. At the moment I'm generating a nice
IO load with badblocks on the failed drive and a backup from the
degregated raid1 to another raid1 (on a seperate bus). During this I'm
playing xmms without much hassle and the system still feels
interactively. However, I have xterm on alt-f1 and if I press it now it
takes about 7 secs to open up. Could be better, but under this
conditions I consider this fair.

Here's a bit of vmstat:

kakerlak:/home/wiktor# vmstat 1 10
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
1  2      0   4752  18376 148028    0    0   895  2655 1162  1952 10 4 79  7
1  2      0   4096  18604 148472    0    0  1988 29344 2360  7481 38 25  0 38
0  2      0   4176  18700 148284    0    0  3296 27363 2317  7298 36 27  0 37
0  2      0   5456  18804 146824    0    0  2392 30567 2161  7177 31 26  0 44
0  3      0   5392  18664 146340    0    0  3544 46644 2172  6894 29 28  0 42
2  3      0   5520  17888 147656    0    0  5568 21068 2173  5776 38 27  0 34
0  2      0   3856  17436 149700    0    0  6656 26464 2122 6654 35 29  0 36
0  2      0   4784  17392 148748    0    0  2324 30532 2175 7277 33 25  0 43
0  2      0   4016  17052 149644    0    0  2620 30412 2175 7214 37 22  0 40
0  3      0   5584  16568 148052    0    0  2632 42131 2163 7040 34 25  0 42
kakerlak:/home/wiktor# 

-- 
Regards,

Wiktor Wodecki

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] O16.2int

[Andrew Morton]

Con Kolivas <kernel@kolivas.org> wrote:
>
> Much simpler

But broken.

The machine runs about 100x slower than normal.  The screensaver cut in
halfway through the initscripts ;) That's on 2-way.  The same kernel works
OK on uniprocessor.

Re: [PATCH] O16.2int

[Con Kolivas]

On Sun, 17 Aug 2003 17:40, Andrew Morton wrote:
> Con Kolivas <kernel@kolivas.org> wrote:
> > Much simpler
>
> But broken.
>
> The machine runs about 100x slower than normal.  The screensaver cut in
> halfway through the initscripts ;) That's on 2-way.  The same kernel works
> OK on uniprocessor.

Good enough. Don't worry about any of the 16s; this drastic change only helped 
the mild case anyway. I'll save only the cleanups and post an incremental to 
16.2 at a later stage.

Con

Re: [PATCH] O16.2int

[Con Kolivas]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

On Sun, 17 Aug 2003 17:40, Andrew Morton wrote:
> Con Kolivas <kernel@kolivas.org> wrote:
> > Much simpler
>
> But broken.
>
> The machine runs about 100x slower than normal.  The screensaver cut in
> halfway through the initscripts ;) That's on 2-way.  The same kernel works
> OK on uniprocessor.

Reverting the !in_interrupt nonsense should be enough to avoid the dreaded 
screensaver at boottime I hope. Does this fix it?

Starvation will be approached differently.

Change:
Make preemption occur as vanilla again except for now not preempting same 
priority tasks with less timeslice.

Con

[-- Attachment #2: patch-O16.2-O16.3int --]
[-- Type: text/x-diff, Size: 468 bytes --]

--- linux-2.6.0-test3-mm2-O16.2/kernel/sched.c	2003-08-18 00:03:53.000000000 +1000
+++ linux-2.6.0-test3-mm2-O16.3/kernel/sched.c	2003-08-18 00:44:20.000000000 +1000
@@ -609,9 +609,8 @@ repeat_lock_task:
 				__activate_task(p, rq);
 			else {
 				activate_task(p, rq);
-				if (TASK_PREEMPTS_CURR(p, rq) &&
-					(in_interrupt() || !p->mm))
-						resched_task(rq->curr);
+				if (TASK_PREEMPTS_CURR(p, rq))
+					resched_task(rq->curr);
 			}
 			success = 1;
 		}

Re: [PATCH] O16.2int

[Andrew Morton]

Con Kolivas <kernel@kolivas.org> wrote:
>
> Reverting the !in_interrupt nonsense should be enough to avoid the dreaded 
>  screensaver at boottime I hope. Does this fix it?

yes, that's a fix.

Re: [PATCH] O16.2int

[Con Kolivas]

On Tue, 19 Aug 2003 02:51, Antonio Vargas wrote:
> On Mon, Aug 18, 2003 at 11:21:04AM +1000, Con Kolivas wrote:
> > Quoting Tom Sightler <ttsig@tuxyturvy.com>:
> > > 2. -- Adobe Acrobat 5.07 for Linux seems to have a very similar issue,
> > > a large complex document seems to starve out the whole system making
> > > the system feel locked up for several seconds.
> >
> > Actually I've profiled acroread and it seems to be more a memory issue
> > than a scheduler one per se. Something very inefficient about it's design
> > and it behaves much worse as a mozilla plugin than standalone. Give it
> > lots of cpu time and it just keeps doing more and more vm work.
>
> Acrobat has a switch so that it keeps a cache of rendered pages, and
> obviously it default to ON, so just reading a big PDF file page by
> page will trash all the system with lots useless data. BUT, for simple
> PDF usage in a non-multitasking single-user machine it's faster
> so there you have a possible reason for it's strange behaviour.

Yes. As well as this though, there is a specific problem with it as a mozilla 
plugin. Profiling shows some libgdk is doing all the work and it really 
behaves badly. Put the same plugin into a different browser (eg opera) and it 
behaves well, working pretty much like standalone acroread. 

Con

Re: [PATCH] O16.2int

[Antonio Vargas]

On Mon, Aug 18, 2003 at 11:21:04AM +1000, Con Kolivas wrote:
> Quoting Tom Sightler <ttsig@tuxyturvy.com>:
> 
> > Hi Con,
> 
> Hi Tom
> 
> > 1. -- Wine running Windows Media Player 6.4 works great when running in
> 
> Yes a well known problem now (see other threads about wine). Wine doing 
> something very cpu intensive exhibits this due to a combination of wine 
> breakage brought out by my scheduler tweaks causing priority inversion.
> 
> > 2. -- Adobe Acrobat 5.07 for Linux seems to have a very similar issue, a
> > large complex document seems to starve out the whole system making the
> > system feel locked up for several seconds.
> 
> Actually I've profiled acroread and it seems to be more a memory issue than a 
> scheduler one per se. Something very inefficient about it's design and it 
> behaves much worse as a mozilla plugin than standalone. Give it lots of cpu 
> time and it just keeps doing more and more vm work.

Acrobat has a switch so that it keeps a cache of rendered pages, and
obviously it default to ON, so just reading a big PDF file page by
page will trash all the system with lots useless data. BUT, for simple
PDF usage in a non-multitasking single-user machine it's faster
so there you have a possible reason for it's strange behaviour.

 
> > 3. -- It seems I can trigger the same kind of starvation by simply doing
> > large selects in a Konsole window.  Selecting a large section of text
> 
> > Konsole issue, however, if another application is using a reasonable
> > amount of CPU, say a video playing in Wine using ~50% CPU, then it seems
> > easy to make this happen.  Once it happens it's very hard to recover,
> 
> This is because of wine, not the Konsole which behaves fine, but tips the 
> combination of wine and something else over the edge.
> 
> I'm working on it. Thanks very much for your report.
> 
> Cheers,
> Con
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
winden/network

1. Dado un programa, siempre tiene al menos un fallo.
2. Dadas varias lineas de codigo, siempre se pueden acortar a menos lineas.
3. Por induccion, todos los programas se pueden
   reducir a una linea que no funciona.

Re: [PATCH] O16.2int

[Con Kolivas]

Quoting Tom Sightler <ttsig@tuxyturvy.com>:

> Hi Con,

Hi Tom

> 1. -- Wine running Windows Media Player 6.4 works great when running in

Yes a well known problem now (see other threads about wine). Wine doing 
something very cpu intensive exhibits this due to a combination of wine 
breakage brought out by my scheduler tweaks causing priority inversion.

> 2. -- Adobe Acrobat 5.07 for Linux seems to have a very similar issue, a
> large complex document seems to starve out the whole system making the
> system feel locked up for several seconds.

Actually I've profiled acroread and it seems to be more a memory issue than a 
scheduler one per se. Something very inefficient about it's design and it 
behaves much worse as a mozilla plugin than standalone. Give it lots of cpu 
time and it just keeps doing more and more vm work.

> 3. -- It seems I can trigger the same kind of starvation by simply doing
> large selects in a Konsole window.  Selecting a large section of text

> Konsole issue, however, if another application is using a reasonable
> amount of CPU, say a video playing in Wine using ~50% CPU, then it seems
> easy to make this happen.  Once it happens it's very hard to recover,

This is because of wine, not the Konsole which behaves fine, but tips the 
combination of wine and something else over the edge.

I'm working on it. Thanks very much for your report.

Cheers,
Con

Re: [PATCH] O16.2int

[Tom Sightler]

Hi Con,

I've been unable to test many of your patches lately, but I recently
upgraded to 2.6.0-test3-mm2 and included the O16.2 patches and I'm
having some very bad behaviour.  I'll try to describe it the best way I
can.

The worst case scenario involves wine applications (a program that seems
to be causing a significant amount of trouble) but I think I've seen the
issue in several other applications as well.

1. -- Wine running Windows Media Player 6.4 works great when running in
a window but if you make the program open to full screen it gets so much
attention that it almost completely starves the entire system, you can't
even manage to get switched back to the standard screen.  If you get
very lucky you can switch the system to a VT and manage, painfully
slowly to kill the wine process off, then the system will turn to
normal.  This issue actually seems to affect almost any wine
applications that's doing a lot of screen updates, for example small
flash animations work OK, but complex animations can cause many seconds
of starvation to the rest of the system.  Renicing the X server and wine
server to much lower numbers seems to make this issue go away.

2. -- Adobe Acrobat 5.07 for Linux seems to have a very similar issue, a
large complex document seems to starve out the whole system making the
system feel locked up for several seconds.

3. -- It seems I can trigger the same kind of starvation by simply doing
large selects in a Konsole window.  Selecting a large section of text
which causes the window to scroll can sometime make the system almost
totally non-responsive in every other window.

The wine issue is the easiest to trigger, the others seem to require
that some other things are also using CPU.  In other words, if the
system is otherwise totally idle I have been unable to trigger the
Konsole issue, however, if another application is using a reasonable
amount of CPU, say a video playing in Wine using ~50% CPU, then it seems
easy to make this happen.  Once it happens it's very hard to recover,
the systems almost completely fails to respond to mouse button clicks
and keyboard functions (although the mouse usually continues to move
smoothly) if I get lucky I can get to a VT and eventually login and kill
something off, but this sometimes takes minutes (it took 90 seconds
earlier today just to get the password prompt after type in my username
at the VT prompt and another minute to get to a shell).

Later,
Tom

Re: [PATCH] O16.2int

[Benjamin Weber]

Hi Con

First of all, thanks a lot for all the hard work on the scheduler. A lot
of people are looking forward to 2.6 and your work is a major part of
the desktop user elements of this next kernel generation. 

I am not one of those who can judge much difference from 15 to 16 e.g.
but I do know that not using any of your patches is a major step back in
interactivity and general feeling of responsiveness of my system. Been
using your patches since the 6th iteration. Back then juk (the kde
jukebox thingy) was a major skipping candidate under heavy load, which
nowadays is almost smooth as silk. 

I am pretty sure when 2.6.0 is released on the world your scheduler is
that fine tuned and matured to make the new kernel a must have for
everyone. And you will get there even when you do not work late at night
each day to get the latest improvments to us as fast as possible hehe.
Just to keep you from too many sleepless nights ;)

Until then I will continue applying your patches  as soon as they get
out and look out for anything suspicious that might catch my attention
=)

Keep up the great work!

--
Ben

Re: [PATCH] O16.2int

[Con Kolivas]

On Sun, 17 Aug 2003 00:41, Nick Piggin wrote:
> Hi Con,
> Up late fixing the scheduler? ;)

Sigh.. yeah it was killing me slowly before and now it's killing me more 
rapidly. Seems I age a year with each patch release. Very occasionally I wish 
I was doing this in daylight hours instead of starting all my hacking at 10pm 
when the family has gone to bed.

> Quick question: have you been Contest-ing your patches much? Would
> you like me to if you haven't the time?

Not as frequently as I'd like no. If you can do nice repeatable runs it would 
be very nice of you thanks. I like to spend as much time as I can testing 
them locally on real world usage, and each time I planned to do some 
benchmarking there was always something else I needed to try after others 
responded. 2.6.0-test3-mm2 #85 doesn't even begin to tell you how many 
kernels I've booted. I've almost rebooted enough to install windows.

If you're interested, this is the script I ran for maximum repeatability in 
minimum timespace of the tests that varied a lot. I had a separate ext3 
partition on another hard disk called /ext3 (explains the command)

oops just noticed you cc'ed lkml. ah what the heck I'll cc it as well
Con

#!/bin/sh
contest -k $1 -o /ext3/dump -n 1 no_load cacherun process_load ctar_load \
xtar_load io_load io_other read_load list_load mem_load dbench_load
contest -k $1 -o /ext3/dump -n 1 process_load ctar_load \
xtar_load io_load io_other read_load list_load mem_load dbench_load
contest -k $1 -o /ext3/dump -n 1 ctar_load \
xtar_load io_load dbench_load
contest -k $1 -o /ext3/dump -n 1 io_load dbench_load
contest -r

Re: [PATCH] O16.2int

[Voluspa]

On Sun, 17 Aug 2003 00:09:06 +1000 Con Kolivas wrote:

> On Sat, 16 Aug 2003 21:07, Voluspa wrote:
> > On 2003-08-16 8:59:48 Con Kolivas wrote:
[...]
> Funny you should mention xmms in the same sentence since that's an app
> that works fine.
[...]
> Now you have to clarify what you mean by game test as being
> impossible. I assume you mean wine based games?
[...]
> If you can profile blender sucking it would be helpful.

I can still starve xmms while running Blender ;-) Game-test
(yes, wine) impossible means it acts almost exactly as I wrote about in:

http://marc.theaimsgroup.com/?l=linux-kernel&m=106098091012383&w=2

We're talking many minutes of total starvation at each stage, start
- menu selection single player - load saved game menu - load game
(haven't had the patience to wait for an actual game to begin...)

Profile Blender? Ok, know nothing about the technique but will compile a
kernel with profiling and read up on what has been mentioned on this
list (Mr Erwin calling for proper "instrumentation")

Will take alot of time. I'll return any restults directly to your
address, won't copy lkml.

Mvh
Mats Johannesson

Re: [PATCH] O16.2int

[Nick Piggin]

Con Kolivas wrote:

>On Sat, 16 Aug 2003 21:07, Voluspa wrote:
>
>>On 2003-08-16 8:59:48 Con Kolivas wrote:
>>
>>>Much simpler
>>>
>>For a coder, perhaps. This user however is facing what feels like a
>>fundamental flaw. The doubling of boot time was fixed, but game-test is
>>pretty much as it was in pure O16 (impossible) and Blender is equally
>>bad - now even the mouse pointer vanishes, becomes invisible, during the
>>10+ second pauses. And it is with Blender as only app running. Didn't
>>dare to start xmms...
>>
>
>Nice. 
>

Hi Con,
Up late fixing the scheduler? ;)
Quick question: have you been Contest-ing your patches much? Would
you like me to if you haven't the time?

Nick

Re: [PATCH] O16.2int

[Con Kolivas]

On Sat, 16 Aug 2003 21:07, Voluspa wrote:
> On 2003-08-16 8:59:48 Con Kolivas wrote:
> > Much simpler
>
> For a coder, perhaps. This user however is facing what feels like a
> fundamental flaw. The doubling of boot time was fixed, but game-test is
> pretty much as it was in pure O16 (impossible) and Blender is equally
> bad - now even the mouse pointer vanishes, becomes invisible, during the
> 10+ second pauses. And it is with Blender as only app running. Didn't
> dare to start xmms...

Nice. 

Funny you should mention xmms in the same sentence since that's an app that 
works fine. I was under no illusion that O16s were going to make these apps 
perform well.  Now you have to clarify what you mean by game test as being 
impossible. I assume you mean wine based games? The only game I own is 
neverwinternights and that performs beautifully. You have to tell me about 
this blender app? I'm unable to fully reproduce these problems here as the 
only thing exhibiting starvation is a mozilla plugin that is busy on wait 
using the libgdk(something) library, and it is usable without starvation 
albeit at sucky performance. If you can profile blender sucking it would be 
helpful. 

> I'll keep running the 2.6.0-test3 ---> O16.2int though. Might pick up
> other cases of regression in lighter usage.

It's not a matter of light versus heavy, it's only select applications. Try 
running your machine at absurd loads (without hitting swap) with apps that 
don't exhibit it. 

Since these are the last thing in my gunsights for the interactivity 
development I'd appreciate as much info as anybody has on what happens when 
they suck, and if profiling can find a common link. Since I own none of the 
apps that do this I can only try to fix them with your help. If someone is 
available for frequent small patch testing that would also be helpful as that 
helped the other interactivity development, so please email me directly.

Con

Re: [PATCH] O16.2int

[Voluspa]

On 2003-08-16 8:59:48 Con Kolivas wrote:

> Much simpler

For a coder, perhaps. This user however is facing what feels like a
fundamental flaw. The doubling of boot time was fixed, but game-test is
pretty much as it was in pure O16 (impossible) and Blender is equally
bad - now even the mouse pointer vanishes, becomes invisible, during the
10+ second pauses. And it is with Blender as only app running. Didn't
dare to start xmms...

I'll keep running the 2.6.0-test3 ---> O16.2int though. Might pick up
other cases of regression in lighter usage.

Mvh
Mats Johannesson