Skip to contentSkip to conversation

O16.2int

PATCH In review Con Kolivas 3 participants 6 messages Aug 16, 2003 – Aug 17, 2003 Scheduler

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 O16.2int

Much simpler

Con

kernel/sched.c +9 -29
@@ -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();
 }
 
include/linux/sched.h +0 -1
@@ -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;
#1 lore raw

Hello Con,

Quoted 3 lines · Con Kolivas

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# 
Signature · 3 lines
Regards,

Wiktor Wodecki
#2 lore raw
In reply to Con Kolivas
Quoted 2 lines · Con Kolivas

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.

#3 lore raw
Quoted 8 lines · Andrew Morton
Quoted 1 line · Con Kolivas

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

#4 lore raw
In reply to Andrew Morton
Quoted 8 lines · Andrew Morton
Quoted 1 line · Con Kolivas

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

kernel/sched.c +2 -3
@@ -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;
 		}
#5 lore raw
Quoted 3 lines · Con Kolivas

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.