Re: 2.5.65-mm2

Re: 2.5.65-mm2

[Charles Baylis]

I'm getting quite a lot of audio skips with this one. 2.5.64-mm8 was the 
last one I tested and it was very good.

2.5.64-mm8 works fine with pretty much any thud load I throw at it, but thud 
3 is enough to cause some skips with 2.5.65-mm2. Thud 5 causes serious 
starvation problems to the whole desktop.

Charlie

Re: 2.5.65-mm2

[Andrew Morton]

Charles Baylis <cb-lkml@fish.zetnet.co.uk> wrote:
>
> 
> I'm getting quite a lot of audio skips with this one. 2.5.64-mm8 was the 
> last one I tested and it was very good.
> 
> 2.5.64-mm8 works fine with pretty much any thud load I throw at it, but thud 
> 3 is enough to cause some skips with 2.5.65-mm2. Thud 5 causes serious 
> starvation problems to the whole desktop.

Please test 2.5.65 base.

Re: 2.5.65-mm2

[Mike Galbraith]

At 11:17 PM 3/19/2003 +0000, Charles Baylis wrote:

>I'm getting quite a lot of audio skips with this one. 2.5.64-mm8 was the
>last one I tested and it was very good.
>
>2.5.64-mm8 works fine with pretty much any thud load I throw at it, but thud
>3 is enough to cause some skips with 2.5.65-mm2. Thud 5 causes serious
>starvation problems to the whole desktop.

My crude hack helped with thud and some others, but is b0rken for others.

         -Mike  

test

[panchi]

test mail

Re: 2.5.65 performance

[John M Flinchbaugh]

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

On Wed, Mar 19, 2003 at 05:38:08PM -0800, Andrew Morton wrote:
> Charles Baylis <cb-lkml@fish.zetnet.co.uk> wrote:
> > I'm getting quite a lot of audio skips with this one. 2.5.64-mm8 
was the 
> > last one I tested and it was very good.
> > 2.5.64-mm8 works fine with pretty much any thud load I throw at it, 
but thud 
> > 3 is enough to cause some skips with 2.5.65-mm2. Thud 5 causes 
serious 
> > starvation problems to the whole desktop.
> Please test 2.5.65 base.

doing normal desktop things (gnome, jboss, mozilla, apt-get updates,
etc) i've noticed audio skips on occassion that i had not seen in
kernels previous to 2.5.65.

i'm not going to complain though, because mozilla seems to start
quicker, and my jboss start time has dropped from 1m:10s average to
40s.  very cool!
-- 
____________________}John Flinchbaugh{______________________
| glynis@hjsoft.com         http://www.hjsoft.com/~glynis/ |
~~Powered by Linux: Reboots are for hardware upgrades only~~

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

Re: 2.5.65 performance

[John Levon]

On Thu, Mar 20, 2003 at 02:44:48PM -0500, John M Flinchbaugh wrote:

> doing normal desktop things (gnome, jboss, mozilla, apt-get updates,
> etc) i've noticed audio skips on occassion that i had not seen in
> kernels previous to 2.5.65.

I've also been seeing this with 2.5.65. 2.5.64 was OK. madplay on .65
skips whilst running wine, mozilla, kde and a couple of gcc's. No
massive drop outs though.

regards,
john

Re: 2.5.65-mm2

[Mike Galbraith]

At 07:16 AM 3/21/2003 +0100, Ingo Molnar wrote:

>On Thu, 20 Mar 2003, Mike Galbraith wrote:
>
> > [...] Virgin .65 is also subject to the positive feedback loop (irman's
> > process load is worst case methinks, and rounding down only ~hides it).
>
>there's no positive feedback loop. What might happen is that in 2.5.65 we
>now distribute the bonus timeslices more widely (the backboost thing), so
>certain workloads might be rated more interactive. But we never give away
>timeslices that were not earned the hard way (ie. via actual sleeping).

(backboost alone is not it, nor is it timeslice granularity alone... bleh)

>i've attached a patch that temporarily turns off the back-boost - does
>that have any measurable impact? [please apply this to -mm1, i do think
>the timeslice-granularity change in -mm1 (-D3) is something we really
>want.]

I still don't have anything worth discussing.

         -Mike

(however, I have been fiddling with the dang thing rather frenetically;)

Yes, this makes a difference.  (everything in sched makes a 
difference)  The basic problem I'm seeing is load detection, and recovery 
from erroneous detection.  When it goes wrong, recovery isn't happening 
here.  cc1 should not ever be called anything but a cpu hog, but I've see 
it and others running at prio 16 (deadly).  This is nice if you're doing 
deadline scheduling, and boost cc1 because it's late, ie intentionally, to 
boost it's throughput.  What I believe happens is that various cpu hogs get 
miss-identified, and get boost with no way other than to fork 
(parent_penalty [100%atm]) or use more cpu than exists. (I think)  This I 
call positive feedback.  The irman process loop is really ugly, and the 
scheduler totally fails to deal with it.  Disabling forward boost actually 
does serious harm to this load.  The best thing you can do for this load 
with the scheduler is to run it at nice 19.  You can get a worst case 
latency of 50ms without much if any tinkering.  (no stockish kernel does 
better than 600ms _ever_ on an otherwise totally idle 500Mhz box 
here.  ~200ms worst case is the _best_ I've gotten by playing with this and 
that priority wise)

There may be something really simple behind the concurrency problems I see 
here.  (bottom line for me is the concurrency problem... I want to 
understand it.  The rest is less than the crux of the biscuit.

(generally, concurrency is much improved, and believe it or not, that's 
exactly what is bugging me so.  Too much is too little is too much.  I'm 
not ready to give up yet.

         -Mike 

Re: 2.5.65-mm2

[Mike Galbraith]

At 07:16 AM 3/21/2003 +0100, Ingo Molnar wrote:

>On Thu, 20 Mar 2003, Mike Galbraith wrote:
>
> > [...] Virgin .65 is also subject to the positive feedback loop (irman's
> > process load is worst case methinks, and rounding down only ~hides it).
>
>there's no positive feedback loop. What might happen is that in 2.5.65 we
>now distribute the bonus timeslices more widely (the backboost thing), so
>certain workloads might be rated more interactive. But we never give away
>timeslices that were not earned the hard way (ie. via actual sleeping).

(backboost alone is not it, nor is it timeslice granularity alone... bleh)

>i've attached a patch that temporarily turns off the back-boost - does
>that have any measurable impact? [please apply this to -mm1, i do think
>the timeslice-granularity change in -mm1 (-D3) is something we really
>want.]

I still don't have anything worth discussing.

         -Mike

(however, I have been fiddling with the dang thing rather frenetically;)

Yes, this makes a difference.  (everything in sched makes a 
difference)  The basic problem I'm seeing is load detection, and recovery 
from erroneous detection.  When it goes wrong, recovery isn't happening 
here.  cc1 should not ever be called anything but a cpu hog, but I've see 
it and others running at prio 16 (deadly).  This is nice if you're doing 
deadline scheduling, and boost cc1 because it's late, ie intentionally, to 
boost it's throughput.  What I believe happens is that various cpu hogs get 
miss-identified, and get boost with no way other than to fork 
(parent_penalty [100%atm]) or use more cpu than exists. (I think)  This I 
call positive feedback.  The irman process loop is really ugly, and the 
scheduler totally fails to deal with it.  Disabling forward boost actually 
does serious harm to this load.  The best thing you can do for this load 
with the scheduler is to run it at nice 19.  You can get a worst case 
latency of 50ms without much if any tinkering.  (no stockish kernel does 
better than 600ms _ever_ on an otherwise totally idle 500Mhz box 
here.  ~200ms worst case is the _best_ I've gotten by playing with this and 
that priority wise)

There may be something really simple behind the concurrency problems I see 
here.  (bottom line for me is the concurrency problem... I want to 
understand it.  The rest is less than the crux of the biscuit.

(generally, concurrency is much improved, and believe it or not, that's 
exactly what is bugging me so.  Too much is too little is too much.  I'm 
not ready to give up yet.

         -Mike 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.65-mm2

[Ingo Molnar]

On Thu, 20 Mar 2003, Mike Galbraith wrote:

> [...] Virgin .65 is also subject to the positive feedback loop (irman's
> process load is worst case methinks, and rounding down only ~hides it).

there's no positive feedback loop. What might happen is that in 2.5.65 we
now distribute the bonus timeslices more widely (the backboost thing), so
certain workloads might be rated more interactive. But we never give away
timeslices that were not earned the hard way (ie. via actual sleeping).

i've attached a patch that temporarily turns off the back-boost - does
that have any measurable impact? [please apply this to -mm1, i do think
the timeslice-granularity change in -mm1 (-D3) is something we really
want.]

	Ingo

--- kernel/sched.c.orig	2003-03-21 07:14:02.000000000 +0100
+++ kernel/sched.c	2003-03-21 07:15:08.000000000 +0100
@@ -365,7 +365,7 @@
 		 * tasks.
 		 */
 		if (sleep_avg > MAX_SLEEP_AVG) {
-			if (!in_interrupt()) {
+			if (0 && !in_interrupt()) {
 				sleep_avg += current->sleep_avg - MAX_SLEEP_AVG;
 				if (sleep_avg > MAX_SLEEP_AVG)
 					sleep_avg = MAX_SLEEP_AVG;

Re: 2.5.65-mm2

[Ingo Molnar]

On Thu, 20 Mar 2003, Mike Galbraith wrote:

> [...] Virgin .65 is also subject to the positive feedback loop (irman's
> process load is worst case methinks, and rounding down only ~hides it).

there's no positive feedback loop. What might happen is that in 2.5.65 we
now distribute the bonus timeslices more widely (the backboost thing), so
certain workloads might be rated more interactive. But we never give away
timeslices that were not earned the hard way (ie. via actual sleeping).

i've attached a patch that temporarily turns off the back-boost - does
that have any measurable impact? [please apply this to -mm1, i do think
the timeslice-granularity change in -mm1 (-D3) is something we really
want.]

	Ingo

--- kernel/sched.c.orig	2003-03-21 07:14:02.000000000 +0100
+++ kernel/sched.c	2003-03-21 07:15:08.000000000 +0100
@@ -365,7 +365,7 @@
 		 * tasks.
 		 */
 		if (sleep_avg > MAX_SLEEP_AVG) {
-			if (!in_interrupt()) {
+			if (0 && !in_interrupt()) {
 				sleep_avg += current->sleep_avg - MAX_SLEEP_AVG;
 				if (sleep_avg > MAX_SLEEP_AVG)
 					sleep_avg = MAX_SLEEP_AVG;

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.65-mm2

[Ingo Molnar]

On Thu, 20 Mar 2003, Mike Galbraith wrote:

> This is a side effect of Ingo's (nice!) latency change methinks.  When
> you have several cpu hogs running (dbench), and they are cleaning your
> cpu's clock by using their full bandwidth to attain maximum throughput,
> and they then break up their timeslice in order to provide you with more
> responsiveness, and then their _cumulative_ sleep time between (round
> robin!) cpu hard burns is added to their sleep_avg, [...]

actually, the round-robining for finer-grained timeslices should not
impact the sleep average at all, because the roundrobin is done while the
task is still _running_, ie. the sleep average does not get impacted.
Otherwise we'd have elevated priority of simple CPU-intensive
applications, which would be Bad.

The way the sleep-average is maintained is balanced very carefully in the
O(1) scheduler. There are three states a task can be in:

 - sleeping: the sleep average increases
 - running but not executing: the sleep average stagnates
 - executing on a CPU: the sleep average decreases

ie. in the roundrobin case the tasks will neither increase, nor decrease
their sleep average - they are in essence 'frozen'. The moment they get
scheduled on a CPU for execution, their sleep average starts to decrease
again. (and once they go to sleep, their sleep average increases.)

so whatever effect you are seeing, it must be something else.

	Ingo

Re: 2.5.65-mm2

[Ingo Molnar]

On Thu, 20 Mar 2003, Mike Galbraith wrote:

> This is a side effect of Ingo's (nice!) latency change methinks.  When
> you have several cpu hogs running (dbench), and they are cleaning your
> cpu's clock by using their full bandwidth to attain maximum throughput,
> and they then break up their timeslice in order to provide you with more
> responsiveness, and then their _cumulative_ sleep time between (round
> robin!) cpu hard burns is added to their sleep_avg, [...]

actually, the round-robining for finer-grained timeslices should not
impact the sleep average at all, because the roundrobin is done while the
task is still _running_, ie. the sleep average does not get impacted.
Otherwise we'd have elevated priority of simple CPU-intensive
applications, which would be Bad.

The way the sleep-average is maintained is balanced very carefully in the
O(1) scheduler. There are three states a task can be in:

 - sleeping: the sleep average increases
 - running but not executing: the sleep average stagnates
 - executing on a CPU: the sleep average decreases

ie. in the roundrobin case the tasks will neither increase, nor decrease
their sleep average - they are in essence 'frozen'. The moment they get
scheduled on a CPU for execution, their sleep average starts to decrease
again. (and once they go to sleep, their sleep average increases.)

so whatever effect you are seeing, it must be something else.

	Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.65-mm2

[Mike Galbraith]

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

At 02:15 PM 3/20/2003 -0700, Steven P. Cole wrote:
>[steven@spc1 linux-2.5.65-mg]$ patch -p1 <../../xx.diff
>patching file include/linux/sched.h
>patching file kernel/fork.c
>patching file kernel/printk.c
>patching file kernel/sched.c
>patch: **** unexpected end of file in patch
>
>It looks like the last hunk has no trailing context lines.
>Did your patch get clobbered?

Must have.  One more time.

         -Mike 

[-- Attachment #2: xx.diff --]
[-- Type: application/octet-stream, Size: 8381 bytes --]

diff -urN linux-2.5.65.virgin/include/linux/sched.h linux-2.5.65/include/linux/sched.h
--- linux-2.5.65.virgin/include/linux/sched.h	Thu Mar 20 22:11:52 2003
+++ linux-2.5.65/include/linux/sched.h	Tue Mar 18 19:19:38 2003
@@ -328,7 +328,8 @@
 	prio_array_t *array;
 
 	unsigned long sleep_avg;
-	unsigned long last_run;
+	unsigned long sleep_begin;
+	unsigned long sleep_end;
 
 	unsigned long policy;
 	unsigned long cpus_allowed;
diff -urN linux-2.5.65.virgin/kernel/fork.c linux-2.5.65/kernel/fork.c
--- linux-2.5.65.virgin/kernel/fork.c	Thu Mar 20 22:11:54 2003
+++ linux-2.5.65/kernel/fork.c	Tue Mar 18 19:23:00 2003
@@ -918,7 +918,7 @@
 	 */
 	p->first_time_slice = 1;
 	current->time_slice >>= 1;
-	p->last_run = jiffies;
+	p->sleep_begin = p->sleep_end = jiffies;
 	if (!current->time_slice) {
 		/*
 	 	 * This case is rare, it happens when the parent has only
diff -urN linux-2.5.65.virgin/kernel/printk.c linux-2.5.65/kernel/printk.c
--- linux-2.5.65.virgin/kernel/printk.c	Thu Mar 20 22:11:54 2003
+++ linux-2.5.65/kernel/printk.c	Wed Mar 19 06:37:45 2003
@@ -510,8 +510,10 @@
 	console_may_schedule = 0;
 	up(&console_sem);
 	spin_unlock_irqrestore(&logbuf_lock, flags);
+#if 0 // MIKEDIDIT
 	if (wake_klogd && !oops_in_progress && waitqueue_active(&log_wait))
 		wake_up_interruptible(&log_wait);
+#endif
 }
 
 /** console_conditional_schedule - yield the CPU if required
diff -urN linux-2.5.65.virgin/kernel/sched.c linux-2.5.65/kernel/sched.c
--- linux-2.5.65.virgin/kernel/sched.c	Thu Mar 20 22:11:54 2003
+++ linux-2.5.65/kernel/sched.c	Thu Mar 20 15:13:34 2003
@@ -67,12 +67,13 @@
 #define MIN_TIMESLICE		( 10 * HZ / 1000)
 #define MAX_TIMESLICE		(200 * HZ / 1000)
 #define CHILD_PENALTY		50
-#define PARENT_PENALTY		100
+#define PARENT_PENALTY		85
 #define EXIT_WEIGHT		3
 #define PRIO_BONUS_RATIO	25
 #define INTERACTIVE_DELTA	2
 #define MAX_SLEEP_AVG		(10*HZ)
-#define STARVATION_LIMIT	(10*HZ)
+#define STARVATION_LIMIT	(1*MAX_TIMESLICE)
+#define TIMESLICE_GRANULARITY	(HZ/20 ?: 1)
 #define NODE_THRESHOLD		125
 
 /*
@@ -332,59 +333,27 @@
 {
 	enqueue_task(p, rq->active);
 	nr_running_inc(rq);
+	p->sleep_end = jiffies;
 }
 
 /*
- * activate_task - move a task to the runqueue and do priority recalculation
- *
- * Update all the scheduling statistics stuff. (sleep average
- * calculation, priority modifiers, etc.)
+ * activate_task - move a task to the runqueue and do priority
+ * recalculation.  If the waker is maximum-interactive, give an
+ * additional boost to the sleeper as well.  This has the effect
+ * of boosting tasks which are related to interactive task.
  */
 static inline int activate_task(task_t *p, runqueue_t *rq)
 {
-	long sleep_time = jiffies - p->last_run - 1;
-	int requeue_waker = 0;
-
-	if (sleep_time > 0) {
-		int sleep_avg;
-
-		/*
-		 * This code gives a bonus to interactive tasks.
-		 *
-		 * The boost works by updating the 'average sleep time'
-		 * value here, based on ->last_run. The more time a task
-		 * spends sleeping, the higher the average gets - and the
-		 * higher the priority boost gets as well.
-		 */
-		sleep_avg = p->sleep_avg + sleep_time;
-
-		/*
-		 * 'Overflow' bonus ticks go to the waker as well, so the
-		 * ticks are not lost. This has the effect of further
-		 * boosting tasks that are related to maximum-interactive
-		 * tasks.
-		 */
-		if (sleep_avg > MAX_SLEEP_AVG) {
-			if (!in_interrupt()) {
-				sleep_avg += current->sleep_avg - MAX_SLEEP_AVG;
-				if (sleep_avg > MAX_SLEEP_AVG)
-					sleep_avg = MAX_SLEEP_AVG;
-
-				if (current->sleep_avg != sleep_avg) {
-					current->sleep_avg = sleep_avg;
-					requeue_waker = 1;
-				}
-			}
-			sleep_avg = MAX_SLEEP_AVG;
-		}
-		if (p->sleep_avg != sleep_avg) {
-			p->sleep_avg = sleep_avg;
-			p->prio = effective_prio(p);
-		}
+	int requeue_waker = in_interrupt();
+	if (!requeue_waker && current->sleep_avg == MAX_SLEEP_AVG) {
+		p->sleep_avg += TIMESLICE_GRANULARITY;
+		if (p->sleep_avg > MAX_SLEEP_AVG)
+			p->sleep_avg = MAX_SLEEP_AVG;
 	}
+	p->prio = effective_prio(p);
 	__activate_task(p, rq);
 
-	return requeue_waker;
+	return requeue_waker ? 0 : TASK_INTERACTIVE(p);
 }
 
 /*
@@ -397,6 +366,7 @@
 		rq->nr_uninterruptible++;
 	dequeue_task(p, p->array);
 	p->array = NULL;
+	p->sleep_begin = jiffies;
 }
 
 /*
@@ -1063,7 +1033,7 @@
 	 */
 
 #define CAN_MIGRATE_TASK(p,rq,this_cpu)					\
-	((jiffies - (p)->last_run > cache_decay_ticks) &&	\
+	((jiffies - (p)->sleep_end > cache_decay_ticks) &&	\
 		!task_running(rq, p) &&					\
 			((p)->cpus_allowed & (1UL << (this_cpu))))
 
@@ -1176,10 +1146,17 @@
  * load-dependent, as the frequency of array switched decreases with
  * increasing number of running tasks:
  */
+#if 0
 #define EXPIRED_STARVING(rq) \
 		(STARVATION_LIMIT && ((rq)->expired_timestamp && \
 		(jiffies - (rq)->expired_timestamp >= \
 			STARVATION_LIMIT * ((rq)->nr_running) + 1)))
+#else
+#define EXPIRED_STARVING(rq) \
+		(STARVATION_LIMIT && ((rq)->expired_timestamp && \
+		(jiffies - (rq)->expired_timestamp >= \
+			STARVATION_LIMIT * ((rq)->active->nr_active) + 1)))
+#endif
 
 /*
  * This function gets called by the timer code, with HZ frequency.
@@ -1194,6 +1171,11 @@
 	runqueue_t *rq = this_rq();
 	task_t *p = current;
 
+	/* Update sleep average. */
+	if (p->sleep_avg)
+		p->sleep_avg--;
+	p->sleep_begin = p->sleep_end = jiffies;
+
 	if (rcu_pending(cpu))
 		rcu_check_callbacks(cpu, user_ticks);
 
@@ -1221,15 +1203,12 @@
 	}
 	spin_lock(&rq->lock);
 	/*
-	 * The task was running during this tick - update the
-	 * time slice counter and the sleep average. Note: we
-	 * do not update a thread's priority until it either
-	 * goes to sleep or uses up its timeslice. This makes
-	 * it possible for interactive tasks to use up their
-	 * timeslices at their highest priority levels.
+	 * The task was running during this tick - update the time
+	 * slice counter. Note: we do not update a thread's priority
+	 * until it either goes to sleep or uses up its timeslice.
+	 * This makes it possible for interactive tasks to use up
+	 * their timeslices at their highest priority levels.
 	 */
-	if (p->sleep_avg)
-		p->sleep_avg--;
 	if (unlikely(rt_task(p))) {
 		/*
 		 * RR tasks need a special form of timeslice management.
@@ -1259,6 +1238,29 @@
 			enqueue_task(p, rq->expired);
 		} else
 			enqueue_task(p, rq->active);
+	} else {
+		/*
+		 * Prevent a too long timeslice from monopolizing the CPU,
+		 * by splitting up the timeslice into smaller pieces.
+		 *
+		 * Note: this does not mean the task's timeslices expire or
+		 * get lost in any way, they just might be preempted by
+		 * another task of equal priority. (one with higher
+		 * priority would have preempted this task already.) We
+		 * requeue this task to the end of the list on this priority
+		 * level, which is in essence a round-robin of tasks with
+		 * equal priority.
+		 */
+		if (!(p->time_slice % TIMESLICE_GRANULARITY) &&
+			       		(p->array == rq->active)) {
+			dequeue_task(p, rq->active);
+			set_tsk_need_resched(p);
+			p->prio = effective_prio(p);
+			enqueue_task(p, rq->active);
+#if 1 // MIKEDIDIT
+			p->sleep_begin += (TIMESLICE_GRANULARITY * rq->active->nr_active);
+#endif
+		}
 	}
 out:
 	spin_unlock(&rq->lock);
@@ -1297,7 +1299,6 @@
 	rq = this_rq();
 
 	release_kernel_lock(prev);
-	prev->last_run = jiffies;
 	spin_lock_irq(&rq->lock);
 
 	/*
@@ -1351,6 +1352,8 @@
 	RCU_qsctr(prev->thread_info->cpu)++;
 
 	if (likely(prev != next)) {
+		static unsigned long time = INITIAL_JIFFIES;  // MIKEDIDIT
+		long slept = 0;
 		rq->nr_switches++;
 		rq->curr = next;
 
@@ -1359,6 +1362,30 @@
 		barrier();
 
 		finish_task_switch(prev);
+		/*
+		 * Update sleep_avg.  Set a limit of MAX_TIMESLICE, and
+		 * try to detect cpu hogs which are doing round robin.
+		 * No sleep bonus for them.
+		 */
+#if 0
+		next->sleep_end = prev->sleep_begin = jiffies;
+#endif
+		slept = next->sleep_end - next->sleep_begin - 1;
+		if (slept > 0) {
+			if (slept > MAX_TIMESLICE)
+				slept = MAX_TIMESLICE;
+			next->sleep_avg += slept;
+			if (next->sleep_avg > MAX_SLEEP_AVG)
+				next->sleep_avg = MAX_SLEEP_AVG;
+		}
+#if 0
+		next->sleep_begin = jiffies;
+#endif
+		if (time_after(jiffies, time)) {
+			time = jiffies + HZ + TIMESLICE_GRANULARITY;
+			printk(KERN_DEBUG "pid %d: slept: %ld  avg: %lu\n",
+				next->pid, slept, next->sleep_avg);
+		}
 	} else
 		spin_unlock_irq(&rq->lock);
 

Re: 2.5.65-mm2

[Steven P. Cole]

On Thu, 2003-03-20 at 14:07, Mike Galbraith wrote:
> At 01:12 PM 3/20/2003 -0700, Steven P. Cole wrote:
> >On Thu, 2003-03-20 at 12:48, Mike Galbraith wrote:
> > > At 07:36 AM 3/20/2003 -0700, Steven Cole wrote:
> > > Bottom line is that once cpu hogs are falsely determined to be sleepers,
> > > positive feedback kills you.
> > >
> > >          -Mike
> > >
> > >
> >Sure, either post a patch against a known sync point, .65, .65-bk, or
> >65-mm2, or send me the sched.c file itself (2600 lines might be a little
> >too much for the entire list).
> >
> >If you send it in the next 2 hours, I can test today, otherwise I'll do
> >it mañana.
> 
> What the heck.  It is attached.
> 
>          -Mike
> 
> (and I repeat, don't _look_, just run it, and let me know;) 

[steven@spc1 linux-2.5.65-mg]$ patch -p1 <../../xx.diff
patching file include/linux/sched.h
patching file kernel/fork.c
patching file kernel/printk.c
patching file kernel/sched.c
patch: **** unexpected end of file in patch

It looks like the last hunk has no trailing context lines.
Did your patch get clobbered?

Steven

Re: 2.5.65-mm2

[Steven P. Cole]

On Thu, 2003-03-20 at 14:07, Mike Galbraith wrote:
> At 01:12 PM 3/20/2003 -0700, Steven P. Cole wrote:
> >On Thu, 2003-03-20 at 12:48, Mike Galbraith wrote:
> > > At 07:36 AM 3/20/2003 -0700, Steven Cole wrote:
> > > Bottom line is that once cpu hogs are falsely determined to be sleepers,
> > > positive feedback kills you.
> > >
> > >          -Mike
> > >
> > >
> >Sure, either post a patch against a known sync point, .65, .65-bk, or
> >65-mm2, or send me the sched.c file itself (2600 lines might be a little
> >too much for the entire list).
> >
> >If you send it in the next 2 hours, I can test today, otherwise I'll do
> >it manana.
> 
> What the heck.  It is attached.
> 
>          -Mike
> 
> (and I repeat, don't _look_, just run it, and let me know;) 

[steven@spc1 linux-2.5.65-mg]$ patch -p1 <../../xx.diff
patching file include/linux/sched.h
patching file kernel/fork.c
patching file kernel/printk.c
patching file kernel/sched.c
patch: **** unexpected end of file in patch

It looks like the last hunk has no trailing context lines.
Did your patch get clobbered?

Steven
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.65-mm2

[Mike Galbraith]

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

At 01:12 PM 3/20/2003 -0700, Steven P. Cole wrote:
>On Thu, 2003-03-20 at 12:48, Mike Galbraith wrote:
> > At 07:36 AM 3/20/2003 -0700, Steven Cole wrote:
> > Bottom line is that once cpu hogs are falsely determined to be sleepers,
> > positive feedback kills you.
> >
> >          -Mike
> >
> >
>Sure, either post a patch against a known sync point, .65, .65-bk, or
>65-mm2, or send me the sched.c file itself (2600 lines might be a little
>too much for the entire list).
>
>If you send it in the next 2 hours, I can test today, otherwise I'll do
>it mañana.

What the heck.  It is attached.

         -Mike

(and I repeat, don't _look_, just run it, and let me know;) 

[-- Attachment #2: xx.diff --]
[-- Type: application/octet-stream, Size: 7788 bytes --]

diff -urN linux-2.5.65.virgin/include/linux/sched.h linux-2.5.65/include/linux/sched.h
--- linux-2.5.65.virgin/include/linux/sched.h	Thu Mar 20 22:11:52 2003
+++ linux-2.5.65/include/linux/sched.h	Tue Mar 18 19:19:38 2003
@@ -328,7 +328,8 @@
 	prio_array_t *array;
 
 	unsigned long sleep_avg;
-	unsigned long last_run;
+	unsigned long sleep_begin;
+	unsigned long sleep_end;
 
 	unsigned long policy;
 	unsigned long cpus_allowed;
diff -urN linux-2.5.65.virgin/kernel/fork.c linux-2.5.65/kernel/fork.c
--- linux-2.5.65.virgin/kernel/fork.c	Thu Mar 20 22:11:54 2003
+++ linux-2.5.65/kernel/fork.c	Tue Mar 18 19:23:00 2003
@@ -918,7 +918,7 @@
 	 */
 	p->first_time_slice = 1;
 	current->time_slice >>= 1;
-	p->last_run = jiffies;
+	p->sleep_begin = p->sleep_end = jiffies;
 	if (!current->time_slice) {
 		/*
 	 	 * This case is rare, it happens when the parent has only
diff -urN linux-2.5.65.virgin/kernel/printk.c linux-2.5.65/kernel/printk.c
--- linux-2.5.65.virgin/kernel/printk.c	Thu Mar 20 22:11:54 2003
+++ linux-2.5.65/kernel/printk.c	Wed Mar 19 06:37:45 2003
@@ -510,8 +510,10 @@
 	console_may_schedule = 0;
 	up(&console_sem);
 	spin_unlock_irqrestore(&logbuf_lock, flags);
+#if 0 // MIKEDIDIT
 	if (wake_klogd && !oops_in_progress && waitqueue_active(&log_wait))
 		wake_up_interruptible(&log_wait);
+#endif
 }
 
 /** console_conditional_schedule - yield the CPU if required
diff -urN linux-2.5.65.virgin/kernel/sched.c linux-2.5.65/kernel/sched.c
--- linux-2.5.65.virgin/kernel/sched.c	Thu Mar 20 22:11:54 2003
+++ linux-2.5.65/kernel/sched.c	Thu Mar 20 15:13:34 2003
@@ -67,12 +67,13 @@
 #define MIN_TIMESLICE		( 10 * HZ / 1000)
 #define MAX_TIMESLICE		(200 * HZ / 1000)
 #define CHILD_PENALTY		50
-#define PARENT_PENALTY		100
+#define PARENT_PENALTY		85
 #define EXIT_WEIGHT		3
 #define PRIO_BONUS_RATIO	25
 #define INTERACTIVE_DELTA	2
 #define MAX_SLEEP_AVG		(10*HZ)
-#define STARVATION_LIMIT	(10*HZ)
+#define STARVATION_LIMIT	(1*MAX_TIMESLICE)
+#define TIMESLICE_GRANULARITY	(HZ/20 ?: 1)
 #define NODE_THRESHOLD		125
 
 /*
@@ -332,59 +333,27 @@
 {
 	enqueue_task(p, rq->active);
 	nr_running_inc(rq);
+	p->sleep_end = jiffies;
 }
 
 /*
- * activate_task - move a task to the runqueue and do priority recalculation
- *
- * Update all the scheduling statistics stuff. (sleep average
- * calculation, priority modifiers, etc.)
+ * activate_task - move a task to the runqueue and do priority
+ * recalculation.  If the waker is maximum-interactive, give an
+ * additional boost to the sleeper as well.  This has the effect
+ * of boosting tasks which are related to interactive task.
  */
 static inline int activate_task(task_t *p, runqueue_t *rq)
 {
-	long sleep_time = jiffies - p->last_run - 1;
-	int requeue_waker = 0;
-
-	if (sleep_time > 0) {
-		int sleep_avg;
-
-		/*
-		 * This code gives a bonus to interactive tasks.
-		 *
-		 * The boost works by updating the 'average sleep time'
-		 * value here, based on ->last_run. The more time a task
-		 * spends sleeping, the higher the average gets - and the
-		 * higher the priority boost gets as well.
-		 */
-		sleep_avg = p->sleep_avg + sleep_time;
-
-		/*
-		 * 'Overflow' bonus ticks go to the waker as well, so the
-		 * ticks are not lost. This has the effect of further
-		 * boosting tasks that are related to maximum-interactive
-		 * tasks.
-		 */
-		if (sleep_avg > MAX_SLEEP_AVG) {
-			if (!in_interrupt()) {
-				sleep_avg += current->sleep_avg - MAX_SLEEP_AVG;
-				if (sleep_avg > MAX_SLEEP_AVG)
-					sleep_avg = MAX_SLEEP_AVG;
-
-				if (current->sleep_avg != sleep_avg) {
-					current->sleep_avg = sleep_avg;
-					requeue_waker = 1;
-				}
-			}
-			sleep_avg = MAX_SLEEP_AVG;
-		}
-		if (p->sleep_avg != sleep_avg) {
-			p->sleep_avg = sleep_avg;
-			p->prio = effective_prio(p);
-		}
+	int requeue_waker = in_interrupt();
+	if (!requeue_waker && current->sleep_avg == MAX_SLEEP_AVG) {
+		p->sleep_avg += TIMESLICE_GRANULARITY;
+		if (p->sleep_avg > MAX_SLEEP_AVG)
+			p->sleep_avg = MAX_SLEEP_AVG;
 	}
+	p->prio = effective_prio(p);
 	__activate_task(p, rq);
 
-	return requeue_waker;
+	return requeue_waker ? 0 : TASK_INTERACTIVE(p);
 }
 
 /*
@@ -397,6 +366,7 @@
 		rq->nr_uninterruptible++;
 	dequeue_task(p, p->array);
 	p->array = NULL;
+	p->sleep_begin = jiffies;
 }
 
 /*
@@ -1063,7 +1033,7 @@
 	 */
 
 #define CAN_MIGRATE_TASK(p,rq,this_cpu)					\
-	((jiffies - (p)->last_run > cache_decay_ticks) &&	\
+	((jiffies - (p)->sleep_end > cache_decay_ticks) &&	\
 		!task_running(rq, p) &&					\
 			((p)->cpus_allowed & (1UL << (this_cpu))))
 
@@ -1176,10 +1146,17 @@
  * load-dependent, as the frequency of array switched decreases with
  * increasing number of running tasks:
  */
+#if 0
 #define EXPIRED_STARVING(rq) \
 		(STARVATION_LIMIT && ((rq)->expired_timestamp && \
 		(jiffies - (rq)->expired_timestamp >= \
 			STARVATION_LIMIT * ((rq)->nr_running) + 1)))
+#else
+#define EXPIRED_STARVING(rq) \
+		(STARVATION_LIMIT && ((rq)->expired_timestamp && \
+		(jiffies - (rq)->expired_timestamp >= \
+			STARVATION_LIMIT * ((rq)->active->nr_active) + 1)))
+#endif
 
 /*
  * This function gets called by the timer code, with HZ frequency.
@@ -1194,6 +1171,11 @@
 	runqueue_t *rq = this_rq();
 	task_t *p = current;
 
+	/* Update sleep average. */
+	if (p->sleep_avg)
+		p->sleep_avg--;
+	p->sleep_begin = p->sleep_end = jiffies;
+
 	if (rcu_pending(cpu))
 		rcu_check_callbacks(cpu, user_ticks);
 
@@ -1221,15 +1203,12 @@
 	}
 	spin_lock(&rq->lock);
 	/*
-	 * The task was running during this tick - update the
-	 * time slice counter and the sleep average. Note: we
-	 * do not update a thread's priority until it either
-	 * goes to sleep or uses up its timeslice. This makes
-	 * it possible for interactive tasks to use up their
-	 * timeslices at their highest priority levels.
+	 * The task was running during this tick - update the time
+	 * slice counter. Note: we do not update a thread's priority
+	 * until it either goes to sleep or uses up its timeslice.
+	 * This makes it possible for interactive tasks to use up
+	 * their timeslices at their highest priority levels.
 	 */
-	if (p->sleep_avg)
-		p->sleep_avg--;
 	if (unlikely(rt_task(p))) {
 		/*
 		 * RR tasks need a special form of timeslice management.
@@ -1259,6 +1238,29 @@
 			enqueue_task(p, rq->expired);
 		} else
 			enqueue_task(p, rq->active);
+	} else {
+		/*
+		 * Prevent a too long timeslice from monopolizing the CPU,
+		 * by splitting up the timeslice into smaller pieces.
+		 *
+		 * Note: this does not mean the task's timeslices expire or
+		 * get lost in any way, they just might be preempted by
+		 * another task of equal priority. (one with higher
+		 * priority would have preempted this task already.) We
+		 * requeue this task to the end of the list on this priority
+		 * level, which is in essence a round-robin of tasks with
+		 * equal priority.
+		 */
+		if (!(p->time_slice % TIMESLICE_GRANULARITY) &&
+			       		(p->array == rq->active)) {
+			dequeue_task(p, rq->active);
+			set_tsk_need_resched(p);
+			p->prio = effective_prio(p);
+			enqueue_task(p, rq->active);
+#if 1 // MIKEDIDIT
+			p->sleep_begin += (TIMESLICE_GRANULARITY * rq->active->nr_active);
+#endif
+		}
 	}
 out:
 	spin_unlock(&rq->lock);
@@ -1297,7 +1299,6 @@
 	rq = this_rq();
 
 	release_kernel_lock(prev);
-	prev->last_run = jiffies;
 	spin_lock_irq(&rq->lock);
 
 	/*
@@ -1351,6 +1352,8 @@
 	RCU_qsctr(prev->thread_info->cpu)++;
 
 	if (likely(prev != next)) {
+		static unsigned long time = INITIAL_JIFFIES;  // MIKEDIDIT
+		long slept = 0;
 		rq->nr_switches++;
 		rq->curr = next;
 
@@ -1359,6 +1362,30 @@
 		barrier();
 
 		finish_task_switch(prev);
+		/*
+		 * Update sleep_avg.  Set a limit of MAX_TIMESLICE, and
+		 * try to detect cpu hogs which are doing round robin.
+		 * No sleep bonus for them.

Re: 2.5.65-mm2

[Steven P. Cole]

On Thu, 2003-03-20 at 12:48, Mike Galbraith wrote:
> At 07:36 AM 3/20/2003 -0700, Steven Cole wrote:
> >On Wed, 2003-03-19 at 21:27, Ed Tomlinson wrote:
> > > On March 19, 2003 06:45 pm, Steven P. Cole wrote:
> > > > On Wed, 2003-03-19 at 17:33, Andrew Morton wrote:
> > > > > "Steven P. Cole" <elenstev@mesatop.com> wrote:
> > > > > > > Summary: using ext3, the simple window shake and scrollbar wiggle
> > > > > > > tests were much improved, but really using Evolution left much 
> > to be
> > > > > > > desired.
> > > > > >
> > > > > > Replying to myself for a followup,
> > > > > >
> > > > > > I repeated the tests with 2.5.65-mm2 elevator=deadline and the
> > > > > > situation was similar to elevator=as.  Running dbench on ext3, the
> > > > > > response to desktop switches and window wiggles was improved over
> > > > > > running dbench on reiserfs, but typing in Evolution was subject 
> > to long
> > > > > > delays with dbench clients greater than 16.
> > > > >
> > > > > OK, final question before I get off my butt and find a way to reproduce
> > > > > this:
> > > > >
> > > > > Does reverting
> > > > >
> > > > > 
> > http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/broken-ou
> > > > >t/sched-2.5.64-D3.patch
> > > > >
> > > > > help?
> > > >
> > > > Sorry, didn't have much time for a lot of testing, but no miracles
> > > > occurred.  With 5 minutes of testing 2.5.65-mm2 and dbench 24 on ext3
> > > > and that patch reverted (first hunk had to be manually fixed), I don't
> > > > see any improvement.  Still the same long long delays in trying to use
> > > > Evolution.
> > >
> > > Steven,
> > >
> > > Do things improve with the patch below applied?  You have to backout the
> > > schedule-tuneables patch before appling it.
> > >
> > > Ed Tomlinson
> >
> >[patch snipped]
> >
> >I tried that patch, and the bad behavior with the Evolution "Compose a
> >Message" window remains.  With a load of dbench 12, I had stalls of many
> >seconds before I could type something.  Also, here is an additional
> >symptom.  If I move the Evolution "Compose" window around rapidly, it
> >leaves a smear of itself on the screen under itself.  With all -mm2
> >variants, this smear stays for an intolerably long time (tens of
> >seconds) while that window does not record keyboard strokes.  2.5.65-bk
> >on the other hand exhibits much more benign behavior.
> 
> This is a side effect of Ingo's (nice!) latency change methinks.  When you 
> have several cpu hogs running (dbench), and they are cleaning your cpu's 
> clock by using their full bandwidth to attain maximum throughput, and they 
> then break up their timeslice in order to provide you with more 
> responsiveness, and then their _cumulative_  sleep time between (round 
> robin!) cpu hard burns is added to their sleep_avg, (boy is this a long 
> sentence) you will (likely) find that they run at a highly elevated 
> priority and starve the devil out of everything else because they can not 
> possibly get enough cpu to eat the sleep_avg they have been given (only way 
> to reduce their priority without forking).  Virgin .65 is also subject to 
> the positive feedback loop (irman's process load is worst case methinks, 
> and rounding down only ~hides it).
> 
> I have a really horrid looking sched.c right now that works around some of 
> this problem in disgusting ways.  If you want to try it, give me a holler 
> before tomorrow morning (slice 'n dice resumes) and I'll rip it out and 
> send it to you.  Fair warning though, if you have good taste, don't look at 
> it at all before applying.  There are a few of spots I wouldn't even want 
> to _try_ to justify.  I don't think dbench will be able to dork it up, but 
> irman's process load (horrible thing) now can again.  (it's pure 
> research... that says a lot;)
> 
> Bottom line is that once cpu hogs are falsely determined to be sleepers, 
> positive feedback kills you.
> 
>          -Mike 
> 
> 
Sure, either post a patch against a known sync point, .65, .65-bk, or
65-mm2, or send me the sched.c file itself (2600 lines might be a little
too much for the entire list).

If you send it in the next 2 hours, I can test today, otherwise I'll do
it mañana.

Steven

Re: 2.5.65-mm2

[Steven P. Cole]

On Thu, 2003-03-20 at 12:48, Mike Galbraith wrote:
> At 07:36 AM 3/20/2003 -0700, Steven Cole wrote:
> >On Wed, 2003-03-19 at 21:27, Ed Tomlinson wrote:
> > > On March 19, 2003 06:45 pm, Steven P. Cole wrote:
> > > > On Wed, 2003-03-19 at 17:33, Andrew Morton wrote:
> > > > > "Steven P. Cole" <elenstev@mesatop.com> wrote:
> > > > > > > Summary: using ext3, the simple window shake and scrollbar wiggle
> > > > > > > tests were much improved, but really using Evolution left much 
> > to be
> > > > > > > desired.
> > > > > >
> > > > > > Replying to myself for a followup,
> > > > > >
> > > > > > I repeated the tests with 2.5.65-mm2 elevator=deadline and the
> > > > > > situation was similar to elevator=as.  Running dbench on ext3, the
> > > > > > response to desktop switches and window wiggles was improved over
> > > > > > running dbench on reiserfs, but typing in Evolution was subject 
> > to long
> > > > > > delays with dbench clients greater than 16.
> > > > >
> > > > > OK, final question before I get off my butt and find a way to reproduce
> > > > > this:
> > > > >
> > > > > Does reverting
> > > > >
> > > > > 
> > http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/broken-ou
> > > > >t/sched-2.5.64-D3.patch
> > > > >
> > > > > help?
> > > >
> > > > Sorry, didn't have much time for a lot of testing, but no miracles
> > > > occurred.  With 5 minutes of testing 2.5.65-mm2 and dbench 24 on ext3
> > > > and that patch reverted (first hunk had to be manually fixed), I don't
> > > > see any improvement.  Still the same long long delays in trying to use
> > > > Evolution.
> > >
> > > Steven,
> > >
> > > Do things improve with the patch below applied?  You have to backout the
> > > schedule-tuneables patch before appling it.
> > >
> > > Ed Tomlinson
> >
> >[patch snipped]
> >
> >I tried that patch, and the bad behavior with the Evolution "Compose a
> >Message" window remains.  With a load of dbench 12, I had stalls of many
> >seconds before I could type something.  Also, here is an additional
> >symptom.  If I move the Evolution "Compose" window around rapidly, it
> >leaves a smear of itself on the screen under itself.  With all -mm2
> >variants, this smear stays for an intolerably long time (tens of
> >seconds) while that window does not record keyboard strokes.  2.5.65-bk
> >on the other hand exhibits much more benign behavior.
> 
> This is a side effect of Ingo's (nice!) latency change methinks.  When you 
> have several cpu hogs running (dbench), and they are cleaning your cpu's 
> clock by using their full bandwidth to attain maximum throughput, and they 
> then break up their timeslice in order to provide you with more 
> responsiveness, and then their _cumulative_  sleep time between (round 
> robin!) cpu hard burns is added to their sleep_avg, (boy is this a long 
> sentence) you will (likely) find that they run at a highly elevated 
> priority and starve the devil out of everything else because they can not 
> possibly get enough cpu to eat the sleep_avg they have been given (only way 
> to reduce their priority without forking).  Virgin .65 is also subject to 
> the positive feedback loop (irman's process load is worst case methinks, 
> and rounding down only ~hides it).
> 
> I have a really horrid looking sched.c right now that works around some of 
> this problem in disgusting ways.  If you want to try it, give me a holler 
> before tomorrow morning (slice 'n dice resumes) and I'll rip it out and 
> send it to you.  Fair warning though, if you have good taste, don't look at 
> it at all before applying.  There are a few of spots I wouldn't even want 
> to _try_ to justify.  I don't think dbench will be able to dork it up, but 
> irman's process load (horrible thing) now can again.  (it's pure 
> research... that says a lot;)
> 
> Bottom line is that once cpu hogs are falsely determined to be sleepers, 
> positive feedback kills you.
> 
>          -Mike 
> 
> 
Sure, either post a patch against a known sync point, .65, .65-bk, or
65-mm2, or send me the sched.c file itself (2600 lines might be a little
too much for the entire list).

If you send it in the next 2 hours, I can test today, otherwise I'll do
it manana.

Steven
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.65-mm2

[Mike Galbraith]

At 07:36 AM 3/20/2003 -0700, Steven Cole wrote:
>On Wed, 2003-03-19 at 21:27, Ed Tomlinson wrote:
> > On March 19, 2003 06:45 pm, Steven P. Cole wrote:
> > > On Wed, 2003-03-19 at 17:33, Andrew Morton wrote:
> > > > "Steven P. Cole" <elenstev@mesatop.com> wrote:
> > > > > > Summary: using ext3, the simple window shake and scrollbar wiggle
> > > > > > tests were much improved, but really using Evolution left much 
> to be
> > > > > > desired.
> > > > >
> > > > > Replying to myself for a followup,
> > > > >
> > > > > I repeated the tests with 2.5.65-mm2 elevator=deadline and the
> > > > > situation was similar to elevator=as.  Running dbench on ext3, the
> > > > > response to desktop switches and window wiggles was improved over
> > > > > running dbench on reiserfs, but typing in Evolution was subject 
> to long
> > > > > delays with dbench clients greater than 16.
> > > >
> > > > OK, final question before I get off my butt and find a way to reproduce
> > > > this:
> > > >
> > > > Does reverting
> > > >
> > > > 
> http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/broken-ou
> > > >t/sched-2.5.64-D3.patch
> > > >
> > > > help?
> > >
> > > Sorry, didn't have much time for a lot of testing, but no miracles
> > > occurred.  With 5 minutes of testing 2.5.65-mm2 and dbench 24 on ext3
> > > and that patch reverted (first hunk had to be manually fixed), I don't
> > > see any improvement.  Still the same long long delays in trying to use
> > > Evolution.
> >
> > Steven,
> >
> > Do things improve with the patch below applied?  You have to backout the
> > schedule-tuneables patch before appling it.
> >
> > Ed Tomlinson
>
>[patch snipped]
>
>I tried that patch, and the bad behavior with the Evolution "Compose a
>Message" window remains.  With a load of dbench 12, I had stalls of many
>seconds before I could type something.  Also, here is an additional
>symptom.  If I move the Evolution "Compose" window around rapidly, it
>leaves a smear of itself on the screen under itself.  With all -mm2
>variants, this smear stays for an intolerably long time (tens of
>seconds) while that window does not record keyboard strokes.  2.5.65-bk
>on the other hand exhibits much more benign behavior.

This is a side effect of Ingo's (nice!) latency change methinks.  When you 
have several cpu hogs running (dbench), and they are cleaning your cpu's 
clock by using their full bandwidth to attain maximum throughput, and they 
then break up their timeslice in order to provide you with more 
responsiveness, and then their _cumulative_  sleep time between (round 
robin!) cpu hard burns is added to their sleep_avg, (boy is this a long 
sentence) you will (likely) find that they run at a highly elevated 
priority and starve the devil out of everything else because they can not 
possibly get enough cpu to eat the sleep_avg they have been given (only way 
to reduce their priority without forking).  Virgin .65 is also subject to 
the positive feedback loop (irman's process load is worst case methinks, 
and rounding down only ~hides it).

I have a really horrid looking sched.c right now that works around some of 
this problem in disgusting ways.  If you want to try it, give me a holler 
before tomorrow morning (slice 'n dice resumes) and I'll rip it out and 
send it to you.  Fair warning though, if you have good taste, don't look at 
it at all before applying.  There are a few of spots I wouldn't even want 
to _try_ to justify.  I don't think dbench will be able to dork it up, but 
irman's process load (horrible thing) now can again.  (it's pure 
research... that says a lot;)

Bottom line is that once cpu hogs are falsely determined to be sleepers, 
positive feedback kills you.

         -Mike 

Re: 2.5.65-mm2

[Mike Galbraith]

At 07:36 AM 3/20/2003 -0700, Steven Cole wrote:
>On Wed, 2003-03-19 at 21:27, Ed Tomlinson wrote:
> > On March 19, 2003 06:45 pm, Steven P. Cole wrote:
> > > On Wed, 2003-03-19 at 17:33, Andrew Morton wrote:
> > > > "Steven P. Cole" <elenstev@mesatop.com> wrote:
> > > > > > Summary: using ext3, the simple window shake and scrollbar wiggle
> > > > > > tests were much improved, but really using Evolution left much 
> to be
> > > > > > desired.
> > > > >
> > > > > Replying to myself for a followup,
> > > > >
> > > > > I repeated the tests with 2.5.65-mm2 elevator=deadline and the
> > > > > situation was similar to elevator=as.  Running dbench on ext3, the
> > > > > response to desktop switches and window wiggles was improved over
> > > > > running dbench on reiserfs, but typing in Evolution was subject 
> to long
> > > > > delays with dbench clients greater than 16.
> > > >
> > > > OK, final question before I get off my butt and find a way to reproduce
> > > > this:
> > > >
> > > > Does reverting
> > > >
> > > > 
> http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/broken-ou
> > > >t/sched-2.5.64-D3.patch
> > > >
> > > > help?
> > >
> > > Sorry, didn't have much time for a lot of testing, but no miracles
> > > occurred.  With 5 minutes of testing 2.5.65-mm2 and dbench 24 on ext3
> > > and that patch reverted (first hunk had to be manually fixed), I don't
> > > see any improvement.  Still the same long long delays in trying to use
> > > Evolution.
> >
> > Steven,
> >
> > Do things improve with the patch below applied?  You have to backout the
> > schedule-tuneables patch before appling it.
> >
> > Ed Tomlinson
>
>[patch snipped]
>
>I tried that patch, and the bad behavior with the Evolution "Compose a
>Message" window remains.  With a load of dbench 12, I had stalls of many
>seconds before I could type something.  Also, here is an additional
>symptom.  If I move the Evolution "Compose" window around rapidly, it
>leaves a smear of itself on the screen under itself.  With all -mm2
>variants, this smear stays for an intolerably long time (tens of
>seconds) while that window does not record keyboard strokes.  2.5.65-bk
>on the other hand exhibits much more benign behavior.

This is a side effect of Ingo's (nice!) latency change methinks.  When you 
have several cpu hogs running (dbench), and they are cleaning your cpu's 
clock by using their full bandwidth to attain maximum throughput, and they 
then break up their timeslice in order to provide you with more 
responsiveness, and then their _cumulative_  sleep time between (round 
robin!) cpu hard burns is added to their sleep_avg, (boy is this a long 
sentence) you will (likely) find that they run at a highly elevated 
priority and starve the devil out of everything else because they can not 
possibly get enough cpu to eat the sleep_avg they have been given (only way 
to reduce their priority without forking).  Virgin .65 is also subject to 
the positive feedback loop (irman's process load is worst case methinks, 
and rounding down only ~hides it).

I have a really horrid looking sched.c right now that works around some of 
this problem in disgusting ways.  If you want to try it, give me a holler 
before tomorrow morning (slice 'n dice resumes) and I'll rip it out and 
send it to you.  Fair warning though, if you have good taste, don't look at 
it at all before applying.  There are a few of spots I wouldn't even want 
to _try_ to justify.  I don't think dbench will be able to dork it up, but 
irman's process load (horrible thing) now can again.  (it's pure 
research... that says a lot;)

Bottom line is that once cpu hogs are falsely determined to be sleepers, 
positive feedback kills you.

         -Mike 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.65-mm2

[Steven Cole]

On Wed, 2003-03-19 at 21:27, Ed Tomlinson wrote:
> On March 19, 2003 06:45 pm, Steven P. Cole wrote:
> > On Wed, 2003-03-19 at 17:33, Andrew Morton wrote:
> > > "Steven P. Cole" <elenstev@mesatop.com> wrote:
> > > > > Summary: using ext3, the simple window shake and scrollbar wiggle
> > > > > tests were much improved, but really using Evolution left much to be
> > > > > desired.
> > > >
> > > > Replying to myself for a followup,
> > > >
> > > > I repeated the tests with 2.5.65-mm2 elevator=deadline and the
> > > > situation was similar to elevator=as.  Running dbench on ext3, the
> > > > response to desktop switches and window wiggles was improved over
> > > > running dbench on reiserfs, but typing in Evolution was subject to long
> > > > delays with dbench clients greater than 16.
> > >
> > > OK, final question before I get off my butt and find a way to reproduce
> > > this:
> > >
> > > Does reverting
> > >
> > > http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/broken-ou
> > >t/sched-2.5.64-D3.patch
> > >
> > > help?
> >
> > Sorry, didn't have much time for a lot of testing, but no miracles
> > occurred.  With 5 minutes of testing 2.5.65-mm2 and dbench 24 on ext3
> > and that patch reverted (first hunk had to be manually fixed), I don't
> > see any improvement.  Still the same long long delays in trying to use
> > Evolution.
> 
> Steven,
> 
> Do things improve with the patch below applied?  You have to backout the 
> schedule-tuneables patch before appling it.
> 
> Ed Tomlinson

[patch snipped]

I tried that patch, and the bad behavior with the Evolution "Compose a
Message" window remains.  With a load of dbench 12, I had stalls of many
seconds before I could type something.  Also, here is an additional
symptom.  If I move the Evolution "Compose" window around rapidly, it
leaves a smear of itself on the screen under itself.  With all -mm2
variants, this smear stays for an intolerably long time (tens of
seconds) while that window does not record keyboard strokes.  2.5.65-bk
on the other hand exhibits much more benign behavior.  Under similar
load, the smear disappears in a few seconds and the window starts
responding to keyboard events.  I just now rebooted 2.5-bk to verify,
and it is still responsive at dbench client loads which would make
Evolution unusable with 2.5.65-mm2.  Mozilla, on the other hand, still
works OK under load with -mm2.  This was all with dbench running on
ext3.

I won't be able to do any more testing for several hours, so have fun!

Steven

Re: 2.5.65-mm2

[Steven Cole]

On Wed, 2003-03-19 at 21:27, Ed Tomlinson wrote:
> On March 19, 2003 06:45 pm, Steven P. Cole wrote:
> > On Wed, 2003-03-19 at 17:33, Andrew Morton wrote:
> > > "Steven P. Cole" <elenstev@mesatop.com> wrote:
> > > > > Summary: using ext3, the simple window shake and scrollbar wiggle
> > > > > tests were much improved, but really using Evolution left much to be
> > > > > desired.
> > > >
> > > > Replying to myself for a followup,
> > > >
> > > > I repeated the tests with 2.5.65-mm2 elevator=deadline and the
> > > > situation was similar to elevator=as.  Running dbench on ext3, the
> > > > response to desktop switches and window wiggles was improved over
> > > > running dbench on reiserfs, but typing in Evolution was subject to long
> > > > delays with dbench clients greater than 16.
> > >
> > > OK, final question before I get off my butt and find a way to reproduce
> > > this:
> > >
> > > Does reverting
> > >
> > > http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/broken-ou
> > >t/sched-2.5.64-D3.patch
> > >
> > > help?
> >
> > Sorry, didn't have much time for a lot of testing, but no miracles
> > occurred.  With 5 minutes of testing 2.5.65-mm2 and dbench 24 on ext3
> > and that patch reverted (first hunk had to be manually fixed), I don't
> > see any improvement.  Still the same long long delays in trying to use
> > Evolution.
> 
> Steven,
> 
> Do things improve with the patch below applied?  You have to backout the 
> schedule-tuneables patch before appling it.
> 
> Ed Tomlinson

[patch snipped]

I tried that patch, and the bad behavior with the Evolution "Compose a
Message" window remains.  With a load of dbench 12, I had stalls of many
seconds before I could type something.  Also, here is an additional
symptom.  If I move the Evolution "Compose" window around rapidly, it
leaves a smear of itself on the screen under itself.  With all -mm2
variants, this smear stays for an intolerably long time (tens of
seconds) while that window does not record keyboard strokes.  2.5.65-bk
on the other hand exhibits much more benign behavior.  Under similar
load, the smear disappears in a few seconds and the window starts
responding to keyboard events.  I just now rebooted 2.5-bk to verify,
and it is still responsive at dbench client loads which would make
Evolution unusable with 2.5.65-mm2.  Mozilla, on the other hand, still
works OK under load with -mm2.  This was all with dbench running on
ext3.

I won't be able to do any more testing for several hours, so have fun!

Steven

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.65-mm2

[Steven Cole]

On Wed, 2003-03-19 at 21:27, Ed Tomlinson wrote:
> On March 19, 2003 06:45 pm, Steven P. Cole wrote:
> > On Wed, 2003-03-19 at 17:33, Andrew Morton wrote:
> > > "Steven P. Cole" <elenstev@mesatop.com> wrote:
> > > > > Summary: using ext3, the simple window shake and scrollbar wiggle
> > > > > tests were much improved, but really using Evolution left much to be
> > > > > desired.
> > > >
> > > > Replying to myself for a followup,
> > > >
> > > > I repeated the tests with 2.5.65-mm2 elevator=deadline and the
> > > > situation was similar to elevator=as.  Running dbench on ext3, the
> > > > response to desktop switches and window wiggles was improved over
> > > > running dbench on reiserfs, but typing in Evolution was subject to long
> > > > delays with dbench clients greater than 16.
> > >
> > > OK, final question before I get off my butt and find a way to reproduce
> > > this:
> > >
> > > Does reverting
> > >
> > > http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/broken-ou
> > >t/sched-2.5.64-D3.patch
> > >
> > > help?
> >
> > Sorry, didn't have much time for a lot of testing, but no miracles
> > occurred.  With 5 minutes of testing 2.5.65-mm2 and dbench 24 on ext3
> > and that patch reverted (first hunk had to be manually fixed), I don't
> > see any improvement.  Still the same long long delays in trying to use
> > Evolution.
> 
> Steven,
> 
> Do things improve with the patch below applied?  You have to backout the 
> schedule-tuneables patch before appling it.

I take it this is the one to back out?
scheduler-tunables.patch 17-Mar-2003 22:01    11k

> 
> Ed Tomlinson

I'll give it a shot when I get the chance.  Unfortunately, I'm bogged
down with meetings tomorrow morning, so it will be at least 14-15 hours
from now.  Perhaps some other adventurous person can pick up the ball in
the meantime.

My test system is 933Mhz PIII, IDE, 256MB. The apps are Mozilla 1.3 and
Evolution 1.2.2 running under KDE 3.1.

Thanks,
Steven

Re: 2.5.65-mm2

[Steven Cole]

On Wed, 2003-03-19 at 21:27, Ed Tomlinson wrote:
> On March 19, 2003 06:45 pm, Steven P. Cole wrote:
> > On Wed, 2003-03-19 at 17:33, Andrew Morton wrote:
> > > "Steven P. Cole" <elenstev@mesatop.com> wrote:
> > > > > Summary: using ext3, the simple window shake and scrollbar wiggle
> > > > > tests were much improved, but really using Evolution left much to be
> > > > > desired.
> > > >
> > > > Replying to myself for a followup,
> > > >
> > > > I repeated the tests with 2.5.65-mm2 elevator=deadline and the
> > > > situation was similar to elevator=as.  Running dbench on ext3, the
> > > > response to desktop switches and window wiggles was improved over
> > > > running dbench on reiserfs, but typing in Evolution was subject to long
> > > > delays with dbench clients greater than 16.
> > >
> > > OK, final question before I get off my butt and find a way to reproduce
> > > this:
> > >
> > > Does reverting
> > >
> > > http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/broken-ou
> > >t/sched-2.5.64-D3.patch
> > >
> > > help?
> >
> > Sorry, didn't have much time for a lot of testing, but no miracles
> > occurred.  With 5 minutes of testing 2.5.65-mm2 and dbench 24 on ext3
> > and that patch reverted (first hunk had to be manually fixed), I don't
> > see any improvement.  Still the same long long delays in trying to use
> > Evolution.
> 
> Steven,
> 
> Do things improve with the patch below applied?  You have to backout the 
> schedule-tuneables patch before appling it.

I take it this is the one to back out?
scheduler-tunables.patch 17-Mar-2003 22:01    11k

> 
> Ed Tomlinson

I'll give it a shot when I get the chance.  Unfortunately, I'm bogged
down with meetings tomorrow morning, so it will be at least 14-15 hours
from now.  Perhaps some other adventurous person can pick up the ball in
the meantime.

My test system is 933Mhz PIII, IDE, 256MB. The apps are Mozilla 1.3 and
Evolution 1.2.2 running under KDE 3.1.

Thanks,
Steven

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.65-mm2

[Mike Galbraith]

At 06:04 PM 3/19/2003 -0500, Robert Love wrote:
>On Wed, 2003-03-19 at 17:51, Steven P. Cole wrote:
>
> > I'll try the different value of max_timeslice with dbench on
> > reiserfs next.  That's where the lack of response was most evident.
>
>I am curious as to whether reverting sched-D4 fixes this.
>
>If not, the first step is seeing whether this is a bad decision made by
>the interactivity estimator.  Something like:
>
>         ps -eo pid,nice,priority,command
>
>for dbench, evolution, and X might be useful.


I think I know what he'll see... elevated priority tasks doing round 
robin.  Watch with top d1 showing only runnable tasks and you can see the 
starvation.

The problem as I see it is that when you have a number of tasks which 
become elevated to interactive status, they'll round robin and starve 
non-interactive tasks basically forever.  This is also why my make -j30 
bzImage introduces concurrency problems.  Despite gcc being a cpu hog, when 
enough of them are running, those which have to wait for more time than 
they consume via cpu usage eventually achieve elevated status and round 
robin until they exit... throttling concurrency.  Limiting the amount of 
boost that a task can gain via one activation helps this problem 
considerably, but does not eliminate it.

(think what happens to EXPIRED_STARVING when you have 30 hogs running, a 
few of them doing round robin, and the rest of them just _waiting_ for that 
queue switch to happen.  :-/  ATM, I'm also gathering sleep time at 
schedule time [friendly tasks gain], so sleep_avg will never be consumed if 
you have more than one hog running.  I made the starvation problem better 
for some loads, but utterly deadly for others.)

Something I'm going to try today (yesterday was educational if not 
wonderfully fruitful) is to limit the amount of time a piggy task can 
remain active in the hope of reducing the time interactive hogs can starve 
their expired brethren.  I'm currently thinking forced expire after some 
number of switches * cpu_usage is reached might cure the starvation without 
destroying sleep_avg.

Suggestions very welcome.  (fun problem:)

         -Mike 

Re: 2.5.65-mm2

[Ed Tomlinson]

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

On March 19, 2003 06:45 pm, Steven P. Cole wrote:
> On Wed, 2003-03-19 at 17:33, Andrew Morton wrote:
> > "Steven P. Cole" <elenstev@mesatop.com> wrote:
> > > > Summary: using ext3, the simple window shake and scrollbar wiggle
> > > > tests were much improved, but really using Evolution left much to be
> > > > desired.
> > >
> > > Replying to myself for a followup,
> > >
> > > I repeated the tests with 2.5.65-mm2 elevator=deadline and the
> > > situation was similar to elevator=as.  Running dbench on ext3, the
> > > response to desktop switches and window wiggles was improved over
> > > running dbench on reiserfs, but typing in Evolution was subject to long
> > > delays with dbench clients greater than 16.
> >
> > OK, final question before I get off my butt and find a way to reproduce
> > this:
> >
> > Does reverting
> >
> > http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/broken-ou
> >t/sched-2.5.64-D3.patch
> >
> > help?
>
> Sorry, didn't have much time for a lot of testing, but no miracles
> occurred.  With 5 minutes of testing 2.5.65-mm2 and dbench 24 on ext3
> and that patch reverted (first hunk had to be manually fixed), I don't
> see any improvement.  Still the same long long delays in trying to use
> Evolution.

Steven,

Do things improve with the patch below applied?  You have to backout the 
schedule-tuneables patch before appling it.

Ed Tomlinson

[-- Attachment #2: ptg-D3-mm2 --]
[-- Type: text/plain, Size: 9225 bytes --]

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1087  -> 1.1088 
#	include/linux/sched.h	1.137   -> 1.138  
#	       kernel/fork.c	1.112   -> 1.113  
#	       kernel/user.c	1.6     -> 1.7    
#	      kernel/sched.c	1.163   -> 1.164  
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/03/07	ed@oscar.et.ca	1.1088
# Add user and thread group governors to prevent either from monoplizing
# the system.  The governors work by limiting the sum of the timeslices
# of active tasks in a group to <n> timeslices.  The defaults set <n> to
# 1.5 for thread groups and to 10 for user tasks.
# 
# For numa systems the governors are per node.  Idealy the storage
# should also be local to the node however, we do not have dynamic per
# node storage yet...
# --------------------------------------------
#
diff -Nru a/include/linux/sched.h b/include/linux/sched.h
--- a/include/linux/sched.h	Sat Mar  8 14:18:48 2003
+++ b/include/linux/sched.h	Sat Mar  8 14:18:48 2003
@@ -178,6 +178,11 @@
 
 #include <linux/aio.h>
 
+struct ptg_struct {		/* pseudo thread groups */
+	atomic_t active[MAX_NUMNODES];
+        atomic_t count;         /* number of refs */
+};
+
 struct mm_struct {
 	struct vm_area_struct * mmap;		/* list of VMAs */
 	struct rb_root mm_rb;
@@ -278,6 +283,7 @@
 struct user_struct {
 	atomic_t __count;	/* reference count */
 	atomic_t processes;	/* How many processes does this user have? */
+	atomic_t active[MAX_NUMNODES];
 	atomic_t files;		/* How many open files does this user have? */
 
 	/* Hash table maintenance information */
@@ -344,6 +350,8 @@
 	struct list_head ptrace_list;
 
 	struct mm_struct *mm, *active_mm;
+	struct ptg_struct * ptgroup;		/* pseudo thread group for this task */
+	atomic_t *governor;			/* the atomic_t that governs this task */
 
 /* task state */
 	struct linux_binfmt *binfmt;
diff -Nru a/kernel/fork.c b/kernel/fork.c
--- a/kernel/fork.c	Sat Mar  8 14:18:48 2003
+++ b/kernel/fork.c	Sat Mar  8 14:18:48 2003
@@ -96,12 +96,24 @@
 	}
 }
 
+void free_ptgroup(struct task_struct *tsk)
+{
+	if (tsk->ptgroup && atomic_sub_and_test(1,&tsk->ptgroup->count)) {
+                kfree(tsk->ptgroup);
+                tsk->ptgroup = NULL;
+                tsk->governor = &tsk->user->active[cpu_to_node(task_cpu(tsk))];
+                if (tsk == current)
+                        atomic_inc(tsk->governor);
+        }
+}
+
 void __put_task_struct(struct task_struct *tsk)
 {
 	WARN_ON(!(tsk->state & (TASK_DEAD | TASK_ZOMBIE)));
 	WARN_ON(atomic_read(&tsk->usage));
 	WARN_ON(tsk == current);
 
+	free_ptgroup(tsk);
 	security_task_free(tsk);
 	free_uid(tsk->user);
 	free_task_struct(tsk);
@@ -469,6 +481,7 @@
 
 	tsk->mm = NULL;
 	tsk->active_mm = NULL;
+	tsk->ptgroup = NULL;
 
 	/*
 	 * Are we cloning a kernel thread?
@@ -734,6 +747,32 @@
 	p->flags = new_flags;
 }
 
+static inline int setup_governor(unsigned long clone_flags, struct task_struct *p)
+{
+	if ( ((clone_flags & CLONE_VM) && (clone_flags & CLONE_FILES)) ||
+	     (clone_flags & CLONE_THREAD)) {
+		if (current->ptgroup)
+			atomic_inc(&current->ptgroup->count);
+		else {
+			int i;
+			current->ptgroup = kmalloc(sizeof(struct ptg_struct), GFP_ATOMIC);
+			if (!current->ptgroup)
+				return 1;
+			/* printk(KERN_INFO "ptgroup - pid %u\n",current->pid); */
+			atomic_set(&current->ptgroup->count,2);
+			for(i=0; i < MAX_NUMNODES; i++)
+				atomic_set(&current->ptgroup->active[i], 0);
+			atomic_set(&current->ptgroup->active[numa_node_id()], 1);
+			atomic_dec(current->governor);
+			current->governor = &current->ptgroup->active[numa_node_id()];
+		}
+		p->ptgroup = current->ptgroup;
+		p->governor = &p->ptgroup->active[numa_node_id()];
+	} else
+		p->governor = &p->user->active[numa_node_id()];
+	return 0;
+}
+
 asmlinkage int sys_set_tid_address(int *tidptr)
 {
 	current->clear_child_tid = tidptr;
@@ -876,6 +915,12 @@
 		goto bad_fork_cleanup_mm;
 	retval = copy_thread(0, clone_flags, stack_start, stack_size, p, regs);
 	if (retval)
+		goto bad_fork_cleanup_namespace;
+	/*
+	 * Setup the governor pointer for the new process, allocating a new ptg as
+	 * required if the process is a thread. 
+	 */
+	if (setup_governor(clone_flags, p))
 		goto bad_fork_cleanup_namespace;
 
 	if (clone_flags & CLONE_CHILD_SETTID)
diff -Nru a/kernel/sched.c b/kernel/sched.c
--- a/kernel/sched.c	Sat Mar  8 14:18:48 2003
+++ b/kernel/sched.c	Sat Mar  8 14:18:48 2003
@@ -68,6 +68,9 @@
 #define MAX_SLEEP_AVG		(10*HZ)
 #define STARVATION_LIMIT	(10*HZ)
 #define NODE_THRESHOLD		125
+#define THREAD_GOVERNOR		15      /* allow threads groups 1.5 full timeslices */
+#define USER_GOVERNOR		100     /* allow user 10 full timeslices */
+
 
 /*
  * If a task is 'interactive' then we reinsert it in the active
@@ -123,7 +126,26 @@
 
 static inline unsigned int task_timeslice(task_t *p)
 {
-	return BASE_TIMESLICE(p);
+	int slice = BASE_TIMESLICE(p);
+	int threads = atomic_read(p->governor) * 10;
+	int govern = threads;
+	if (p->user->uid)
+		govern = (p->ptgroup) ? THREAD_GOVERNOR : USER_GOVERNOR;
+	if (threads > govern) {
+		slice = (slice * govern) / threads;
+		slice = (slice > MIN_TIMESLICE) ? slice : MIN_TIMESLICE;
+	}
+#if 0
+	{
+		static int next;
+		if (time_after(jiffies, next)) {
+			printk(KERN_INFO "uid %d pid %d nod %d ptg %x gov %x threads %d lim %d slice %d\n",
+			  p->uid, p->pid, numa_node_id(), p->ptgroup, p->governor, threads/10, govern, slice);
+			next = jiffies + HZ*300;
+		}
+	}
+#endif
+	return slice;
 }
 
 /*
@@ -197,16 +219,18 @@
 	rq->node_nr_running = &node_nr_running[0];
 }
 
-static inline void nr_running_inc(runqueue_t *rq)
+static inline void nr_running_inc(task_t *p, runqueue_t *rq)
 {
 	atomic_inc(rq->node_nr_running);
 	rq->nr_running++;
+	atomic_inc(p->governor);
 }
 
-static inline void nr_running_dec(runqueue_t *rq)
+static inline void nr_running_dec(task_t *p, runqueue_t *rq)
 {
 	atomic_dec(rq->node_nr_running);
 	rq->nr_running--;
+	atomic_dec(p->governor);
 }
 
 __init void node_nr_running_init(void)
@@ -220,8 +244,8 @@
 #else /* !CONFIG_NUMA */
 
 # define nr_running_init(rq)   do { } while (0)
-# define nr_running_inc(rq)    do { (rq)->nr_running++; } while (0)
-# define nr_running_dec(rq)    do { (rq)->nr_running--; } while (0)
+# define nr_running_inc(p, rq)    do { (rq)->nr_running++; atomic_inc((p)->governor); } while (0)
+# define nr_running_dec(p, rq)    do { (rq)->nr_running--; atomic_dec((p)->governor); } while (0)
 
 #endif /* CONFIG_NUMA */
 
@@ -326,7 +350,7 @@
 static inline void __activate_task(task_t *p, runqueue_t *rq)
 {
 	enqueue_task(p, rq->active);
-	nr_running_inc(rq);
+	nr_running_inc(p, rq);
 }
 
 /*
@@ -387,7 +411,7 @@
  */
 static inline void deactivate_task(struct task_struct *p, runqueue_t *rq)
 {
-	nr_running_dec(rq);
+	nr_running_dec(p, rq);
 	if (p->state == TASK_UNINTERRUPTIBLE)
 		rq->nr_uninterruptible++;
 	dequeue_task(p, p->array);
@@ -586,7 +610,7 @@
 		list_add_tail(&p->run_list, &current->run_list);
 		p->array = current->array;
 		p->array->nr_active++;
-		nr_running_inc(rq);
+		nr_running_inc(p, rq);
 	}
 	task_rq_unlock(rq, &flags);
 }
@@ -1004,9 +1028,15 @@
 static inline void pull_task(runqueue_t *src_rq, prio_array_t *src_array, task_t *p, runqueue_t *this_rq, int this_cpu)
 {
 	dequeue_task(p, src_array);
-	nr_running_dec(src_rq);
+	nr_running_dec(p, src_rq);
 	set_task_cpu(p, this_cpu);
-	nr_running_inc(this_rq);
+#ifdef CONFIG_NUMA
+        if (p->ptgroup)
+                p->governor = &p->ptgroup->active[cpu_to_node(this_cpu)];
+        else
+                p->governor = &p->user->active[cpu_to_node(this_cpu)];
+#endif
+	nr_running_inc(p, this_rq);
 	enqueue_task(p, this_rq->active);
 	/*
 	 * Note that idle threads have a prio of MAX_PRIO, for this test
@@ -2521,6 +2551,8 @@
 	rq->curr = current;
 	rq->idle = current;
 	set_task_cpu(current, smp_processor_id());
+        current->governor = &current->user->active[numa_node_id()];
+	atomic_inc(current->governor);
 	wake_up_forked_process(current);
 	current->prio = MAX_PRIO;
 
diff -Nru a/kernel/user.c b/kernel/user.c
--- a/kernel/user.c	Sat Mar  8 14:18:48 2003
+++ b/kernel/user.c	Sat Mar  8 14:18:48 2003
@@ -30,6 +30,7 @@
 struct user_struct root_user = {
 	.__count	= ATOMIC_INIT(1),
 	.processes	= ATOMIC_INIT(1),
+	.active		= {[0 ...MAX_NUMNODES-1] = ATOMIC_INIT(0)},
 	.files		= ATOMIC_INIT(0)
 };
 
@@ -89,6 +90,7 @@
 
 	if (!up) {
 		struct user_struct *new;
+		int i;
 
 		new = kmem_cache_alloc(uid_cachep, SLAB_KERNEL);
 		if (!new)
@@ -96,6 +98,8 @@
 		new->uid = uid;
 		atomic_set(&new->__count, 1);
 		atomic_set(&new->processes, 0);
+		for(i=0; i < MAX_NUMNODES; i++)
+			atomic_set(&new->active[i], 0);
 		atomic_set(&new->files, 0);
 
 		/*
@@ -130,6 +134,11 @@
 	atomic_inc(&new_user->processes);
 	atomic_dec(&old_user->processes);
 	current->user = new_user;
+	if (!current->ptgroup) {
+		atomic_dec(current->governor);
+		current->governor = &current->user->active[numa_node_id()];
+		atomic_inc(current->governor);
+	}
 	free_uid(old_user);
 }
 

Re: 2.5.65-mm2

[Andrew Morton]

"Steven P. Cole" <elenstev@mesatop.com> wrote:
>
> > 
> > Summary: using ext3, the simple window shake and scrollbar wiggle tests
> > were much improved, but really using Evolution left much to be desired.
> 
> Replying to myself for a followup,
> 
> I repeated the tests with 2.5.65-mm2 elevator=deadline and the situation
> was similar to elevator=as.  Running dbench on ext3, the response to
> desktop switches and window wiggles was improved over running dbench on
> reiserfs, but typing in Evolution was subject to long delays with dbench
> clients greater than 16.

OK, final question before I get off my butt and find a way to reproduce this:

Does reverting

http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/broken-out/sched-2.5.64-D3.patch

help?

Re: 2.5.65-mm2

[Andrew Morton]

"Steven P. Cole" <elenstev@mesatop.com> wrote:
>
> > 
> > Summary: using ext3, the simple window shake and scrollbar wiggle tests
> > were much improved, but really using Evolution left much to be desired.
> 
> Replying to myself for a followup,
> 
> I repeated the tests with 2.5.65-mm2 elevator=deadline and the situation
> was similar to elevator=as.  Running dbench on ext3, the response to
> desktop switches and window wiggles was improved over running dbench on
> reiserfs, but typing in Evolution was subject to long delays with dbench
> clients greater than 16.

OK, final question before I get off my butt and find a way to reproduce this:

Does reverting

http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/broken-out/sched-2.5.64-D3.patch

help?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.65-mm2

[Steven P. Cole]

On Wed, 2003-03-19 at 17:33, Andrew Morton wrote:
> "Steven P. Cole" <elenstev@mesatop.com> wrote:
> >
> > > 
> > > Summary: using ext3, the simple window shake and scrollbar wiggle tests
> > > were much improved, but really using Evolution left much to be desired.
> > 
> > Replying to myself for a followup,
> > 
> > I repeated the tests with 2.5.65-mm2 elevator=deadline and the situation
> > was similar to elevator=as.  Running dbench on ext3, the response to
> > desktop switches and window wiggles was improved over running dbench on
> > reiserfs, but typing in Evolution was subject to long delays with dbench
> > clients greater than 16.
> 
> OK, final question before I get off my butt and find a way to reproduce this:
> 
> Does reverting
> 
> http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/broken-out/sched-2.5.64-D3.patch
> 
> help?

Sorry, didn't have much time for a lot of testing, but no miracles
occurred.  With 5 minutes of testing 2.5.65-mm2 and dbench 24 on ext3
and that patch reverted (first hunk had to be manually fixed), I don't
see any improvement.  Still the same long long delays in trying to use
Evolution. 

Steven

Re: 2.5.65-mm2

[Steven P. Cole]

On Wed, 2003-03-19 at 17:33, Andrew Morton wrote:
> "Steven P. Cole" <elenstev@mesatop.com> wrote:
> >
> > > 
> > > Summary: using ext3, the simple window shake and scrollbar wiggle tests
> > > were much improved, but really using Evolution left much to be desired.
> > 
> > Replying to myself for a followup,
> > 
> > I repeated the tests with 2.5.65-mm2 elevator=deadline and the situation
> > was similar to elevator=as.  Running dbench on ext3, the response to
> > desktop switches and window wiggles was improved over running dbench on
> > reiserfs, but typing in Evolution was subject to long delays with dbench
> > clients greater than 16.
> 
> OK, final question before I get off my butt and find a way to reproduce this:
> 
> Does reverting
> 
> http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/broken-out/sched-2.5.64-D3.patch
> 
> help?

Sorry, didn't have much time for a lot of testing, but no miracles
occurred.  With 5 minutes of testing 2.5.65-mm2 and dbench 24 on ext3
and that patch reverted (first hunk had to be manually fixed), I don't
see any improvement.  Still the same long long delays in trying to use
Evolution. 

Steven
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.65-mm2

[Steven P. Cole]

On Wed, 2003-03-19 at 16:04, Robert Love wrote:
> On Wed, 2003-03-19 at 17:51, Steven P. Cole wrote:
> 
> > I'll try the different value of max_timeslice with dbench on
> > reiserfs next.  That's where the lack of response was most evident.
> 
> I am curious as to whether reverting sched-D4 fixes this.
> 
> If not, the first step is seeing whether this is a bad decision made by
> the interactivity estimator.  Something like:
> 
> 	ps -eo pid,nice,priority,command
> 
> for dbench, evolution, and X might be useful.
> 
> Thanks,
> 
> 	Robert Love
> 
In the meantime, Andrew has asked me to revert the sched-D3 patch.  I'm
recompiling now, and will only have time for that test before I have to
go do other things.

Steven

Re: 2.5.65-mm2

[jjs]

Steven P. Cole wrote

>[root@spc1 steven]# cat /proc/sys/sched/max_timeslice
>200
>[root@spc1 steven]# echo 50 >/proc/sys/sched/max_timeslice
>[root@spc1 steven]# cat /proc/sys/sched/max_timeslice
>50
>
>Ouch. I inserted the above text saved as a file, and had to wait
>over a minute after hitting the OK button.  I aborted dbench which was
>running 24 clients on ext3 just to finish this.
>
hmm, I'd always made this sort of change
under somewhat quiescent conditions  -

Interesting results though - it helped on my
system in terms of desktop smoothness, i.e.
visible stuttering of xterm motion when being
dragged around the desktop during dbench -

Joe

Re: 2.5.65-mm2

[Robert Love]

On Wed, 2003-03-19 at 17:51, Steven P. Cole wrote:

> I'll try the different value of max_timeslice with dbench on
> reiserfs next.  That's where the lack of response was most evident.

I am curious as to whether reverting sched-D4 fixes this.

If not, the first step is seeing whether this is a bad decision made by
the interactivity estimator.  Something like:

	ps -eo pid,nice,priority,command

for dbench, evolution, and X might be useful.

Thanks,

	Robert Love

Re: 2.5.65-mm2

[Steven P. Cole]

On Wed, 2003-03-19 at 15:17, jjs wrote:
> Steven P. Cole wrote:
> 
> >I repeated the tests with 2.5.65-mm2 elevator=deadline and the situation
> >was similar to elevator=as.  Running dbench on ext3, the response to
> >desktop switches and window wiggles was improved over running dbench on
> >reiserfs, but typing in Evolution was subject to long delays with dbench
> >clients greater than 16.
> >
> >I rebooted with 2.5.65-bk and ran dbench on ext3 again.  Everything was
> >going smoothly, excellent interactivity, and then with dbench 28, the
> >system froze.  No response to pings, no response to alt-sysrq-b (after
> >alt-sysrq-s).  A hard reset was required.  Nothing interesting logged.
> >Too bad.  Before it crashed, 2.5.65-bk was responding to typing in an
> >Evolution new message window better than -mm2.
> >
> 
> Just out of curiosity, what is the result of:
> 
> cat /proc/sys/sched/max_timeslice?
> 
> Does setting that to e.g. 50 make -mm2 smooth?
> 
> Joe

[root@spc1 steven]# cat /proc/sys/sched/max_timeslice
200
[root@spc1 steven]# echo 50 >/proc/sys/sched/max_timeslice
[root@spc1 steven]# cat /proc/sys/sched/max_timeslice
50

Ouch. I inserted the above text saved as a file, and had to wait
over a minute after hitting the OK button.  I aborted dbench which was
running 24 clients on ext3 just to finish this.

The change in max_timeslice didn't seem to improve things.

Apart from the little matter of crashing, 2.5-bk was more usable at that
and higher loads.

I'll try the different value of max_timeslice with dbench on reiserfs
next.  That's where the lack of response was most evident.

Steven

Re: 2.5.65-mm2

[jjs]

Steven P. Cole wrote:

>I repeated the tests with 2.5.65-mm2 elevator=deadline and the situation
>was similar to elevator=as.  Running dbench on ext3, the response to
>desktop switches and window wiggles was improved over running dbench on
>reiserfs, but typing in Evolution was subject to long delays with dbench
>clients greater than 16.
>
>I rebooted with 2.5.65-bk and ran dbench on ext3 again.  Everything was
>going smoothly, excellent interactivity, and then with dbench 28, the
>system froze.  No response to pings, no response to alt-sysrq-b (after
>alt-sysrq-s).  A hard reset was required.  Nothing interesting logged.
>Too bad.  Before it crashed, 2.5.65-bk was responding to typing in an
>Evolution new message window better than -mm2.
>

Just out of curiosity, what is the result of:

cat /proc/sys/sched/max_timeslice?

Does setting that to e.g. 50 make -mm2 smooth?

Joe

Re: 2.5.65-mm2

[Steven P. Cole]

On Wed, 2003-03-19 at 13:57, Steven P. Cole wrote:
> On Wed, 2003-03-19 at 13:10, Andrew Morton wrote:
> > Steven Cole <elenstev@mesatop.com> wrote:
> > >
> > > On Wed, 2003-03-19 at 02:21, Andrew Morton wrote:
> > > > 
> > > > http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/
> > > > 
> > > 
> > > I am seeing a significant degradation of interactivity under load with
> > > recent -mm kernels.  The load is dbench on a reiserfs file system with
> > > increasing numbers of clients.  The test machine is single PIII, IDE,
> > > 256MB memory, all kernels PREEMPT.
> > 
> > (This email brought to you while running dbench 128 on ext3)
> > 
> > There's a pretty big reiserfs patch in -mm.  Are you able to whip up
> > an ext2 partition and see if that displays the same problem?
> > 
> 
> I repeated the test on an ext3 partition, and the response with 28
> dbench clients running is definitely better, although I'm starting to
> get some stalls of a couple seconds while typing this in Evolution on
> the machine under test.  Now it's becoming intolerable, so I aborted the
> dbench run so I could finish this email.
> 
> This was with 2.5.65-mm2 and elevator=as.  I'll repeat soon with
> elevator=deadline.  I didn't try typing in Evolution with 2.5.65-bk
> under high loads, so I'll also give that a try.
> 
> Summary: using ext3, the simple window shake and scrollbar wiggle tests
> were much improved, but really using Evolution left much to be desired.

Replying to myself for a followup,

I repeated the tests with 2.5.65-mm2 elevator=deadline and the situation
was similar to elevator=as.  Running dbench on ext3, the response to
desktop switches and window wiggles was improved over running dbench on
reiserfs, but typing in Evolution was subject to long delays with dbench
clients greater than 16.

I rebooted with 2.5.65-bk and ran dbench on ext3 again.  Everything was
going smoothly, excellent interactivity, and then with dbench 28, the
system froze.  No response to pings, no response to alt-sysrq-b (after
alt-sysrq-s).  A hard reset was required.  Nothing interesting logged.
Too bad.  Before it crashed, 2.5.65-bk was responding to typing in an
Evolution new message window better than -mm2.

I'll see if this is repeatable.

Steven

Re: 2.5.65-mm2

[Steven P. Cole]

On Wed, 2003-03-19 at 13:57, Steven P. Cole wrote:
> On Wed, 2003-03-19 at 13:10, Andrew Morton wrote:
> > Steven Cole <elenstev@mesatop.com> wrote:
> > >
> > > On Wed, 2003-03-19 at 02:21, Andrew Morton wrote:
> > > > 
> > > > http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/
> > > > 
> > > 
> > > I am seeing a significant degradation of interactivity under load with
> > > recent -mm kernels.  The load is dbench on a reiserfs file system with
> > > increasing numbers of clients.  The test machine is single PIII, IDE,
> > > 256MB memory, all kernels PREEMPT.
> > 
> > (This email brought to you while running dbench 128 on ext3)
> > 
> > There's a pretty big reiserfs patch in -mm.  Are you able to whip up
> > an ext2 partition and see if that displays the same problem?
> > 
> 
> I repeated the test on an ext3 partition, and the response with 28
> dbench clients running is definitely better, although I'm starting to
> get some stalls of a couple seconds while typing this in Evolution on
> the machine under test.  Now it's becoming intolerable, so I aborted the
> dbench run so I could finish this email.
> 
> This was with 2.5.65-mm2 and elevator=as.  I'll repeat soon with
> elevator=deadline.  I didn't try typing in Evolution with 2.5.65-bk
> under high loads, so I'll also give that a try.
> 
> Summary: using ext3, the simple window shake and scrollbar wiggle tests
> were much improved, but really using Evolution left much to be desired.

Replying to myself for a followup,

I repeated the tests with 2.5.65-mm2 elevator=deadline and the situation
was similar to elevator=as.  Running dbench on ext3, the response to
desktop switches and window wiggles was improved over running dbench on
reiserfs, but typing in Evolution was subject to long delays with dbench
clients greater than 16.

I rebooted with 2.5.65-bk and ran dbench on ext3 again.  Everything was
going smoothly, excellent interactivity, and then with dbench 28, the
system froze.  No response to pings, no response to alt-sysrq-b (after
alt-sysrq-s).  A hard reset was required.  Nothing interesting logged.
Too bad.  Before it crashed, 2.5.65-bk was responding to typing in an
Evolution new message window better than -mm2.

I'll see if this is repeatable.

Steven
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.65-mm2

[Steven P. Cole]

On Wed, 2003-03-19 at 13:10, Andrew Morton wrote:
> Steven Cole <elenstev@mesatop.com> wrote:
> >
> > On Wed, 2003-03-19 at 02:21, Andrew Morton wrote:
> > > 
> > > http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/
> > > 
> > 
> > I am seeing a significant degradation of interactivity under load with
> > recent -mm kernels.  The load is dbench on a reiserfs file system with
> > increasing numbers of clients.  The test machine is single PIII, IDE,
> > 256MB memory, all kernels PREEMPT.
> 
> (This email brought to you while running dbench 128 on ext3)
> 
> There's a pretty big reiserfs patch in -mm.  Are you able to whip up
> an ext2 partition and see if that displays the same problem?
> 

I repeated the test on an ext3 partition, and the response with 28
dbench clients running is definitely better, although I'm starting to
get some stalls of a couple seconds while typing this in Evolution on
the machine under test.  Now it's becoming intolerable, so I aborted the
dbench run so I could finish this email.

This was with 2.5.65-mm2 and elevator=as.  I'll repeat soon with
elevator=deadline.  I didn't try typing in Evolution with 2.5.65-bk
under high loads, so I'll also give that a try.

Summary: using ext3, the simple window shake and scrollbar wiggle tests
were much improved, but really using Evolution left much to be desired.

Steven

Re: 2.5.65-mm2

[Steven P. Cole]

On Wed, 2003-03-19 at 13:10, Andrew Morton wrote:
> Steven Cole <elenstev@mesatop.com> wrote:
> >
> > On Wed, 2003-03-19 at 02:21, Andrew Morton wrote:
> > > 
> > > http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/
> > > 
> > 
> > I am seeing a significant degradation of interactivity under load with
> > recent -mm kernels.  The load is dbench on a reiserfs file system with
> > increasing numbers of clients.  The test machine is single PIII, IDE,
> > 256MB memory, all kernels PREEMPT.
> 
> (This email brought to you while running dbench 128 on ext3)
> 
> There's a pretty big reiserfs patch in -mm.  Are you able to whip up
> an ext2 partition and see if that displays the same problem?
> 

I repeated the test on an ext3 partition, and the response with 28
dbench clients running is definitely better, although I'm starting to
get some stalls of a couple seconds while typing this in Evolution on
the machine under test.  Now it's becoming intolerable, so I aborted the
dbench run so I could finish this email.

This was with 2.5.65-mm2 and elevator=as.  I'll repeat soon with
elevator=deadline.  I didn't try typing in Evolution with 2.5.65-bk
under high loads, so I'll also give that a try.

Summary: using ext3, the simple window shake and scrollbar wiggle tests
were much improved, but really using Evolution left much to be desired.

Steven
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.65-mm2

[Andrew Morton]

Steven Cole <elenstev@mesatop.com> wrote:
>
> On Wed, 2003-03-19 at 02:21, Andrew Morton wrote:
> > 
> > http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/
> > 
> 
> I am seeing a significant degradation of interactivity under load with
> recent -mm kernels.  The load is dbench on a reiserfs file system with
> increasing numbers of clients.  The test machine is single PIII, IDE,
> 256MB memory, all kernels PREEMPT.

(This email brought to you while running dbench 128 on ext3)

There's a pretty big reiserfs patch in -mm.  Are you able to whip up
an ext2 partition and see if that displays the same problem?

Re: 2.5.65-mm2

[Andrew Morton]

Steven Cole <elenstev@mesatop.com> wrote:
>
> On Wed, 2003-03-19 at 02:21, Andrew Morton wrote:
> > 
> > http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/
> > 
> 
> I am seeing a significant degradation of interactivity under load with
> recent -mm kernels.  The load is dbench on a reiserfs file system with
> increasing numbers of clients.  The test machine is single PIII, IDE,
> 256MB memory, all kernels PREEMPT.

(This email brought to you while running dbench 128 on ext3)

There's a pretty big reiserfs patch in -mm.  Are you able to whip up
an ext2 partition and see if that displays the same problem?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.65-mm2

[Steven Cole]

On Wed, 2003-03-19 at 02:21, Andrew Morton wrote:
> 
> http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/
> 

I am seeing a significant degradation of interactivity under load with
recent -mm kernels.  The load is dbench on a reiserfs file system with
increasing numbers of clients.  The test machine is single PIII, IDE,
256MB memory, all kernels PREEMPT.

Specifying elevator=deadline improved the response of 2.5.65-mm2
somewhat, but it still eventually became intolerably slow with
sufficient load.

Interactivity tests consisted of switching between desktops with two
instances of Mozilla 1.3 on separate desktops, and Evolution 1.2.2 on
another desktop.  Additional tests included shaking the window and
wiggling the scrollbar.

The third and fourth columns list the number of dbench clients at which
interactivity becomes poor, or intolerable, defined here as getting a
response after:

good		less than 1 second
poor		seconds
intolerable	tens of seconds

kernel			interactivity under load (dbench clients)
			good	poor 	intolerable

2.5.65-bk		 56*
2.5.65-mm1		 <8	16	24
2.5.65-mm2		 <8	16	24
2.5.65-mm2 deadline	 <8	20	28

*2.5.65-bk was still performing very well at dbench 56.  I'll continue
to test up to 128 clients.

2.5.65-bk was updated with a bk pull this morning.

Steven

Re: 2.5.65-mm2

[Steven Cole]

On Wed, 2003-03-19 at 02:21, Andrew Morton wrote:
> 
> http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/
> 

I am seeing a significant degradation of interactivity under load with
recent -mm kernels.  The load is dbench on a reiserfs file system with
increasing numbers of clients.  The test machine is single PIII, IDE,
256MB memory, all kernels PREEMPT.

Specifying elevator=deadline improved the response of 2.5.65-mm2
somewhat, but it still eventually became intolerably slow with
sufficient load.

Interactivity tests consisted of switching between desktops with two
instances of Mozilla 1.3 on separate desktops, and Evolution 1.2.2 on
another desktop.  Additional tests included shaking the window and
wiggling the scrollbar.

The third and fourth columns list the number of dbench clients at which
interactivity becomes poor, or intolerable, defined here as getting a
response after:

good		less than 1 second
poor		seconds
intolerable	tens of seconds

kernel			interactivity under load (dbench clients)
			good	poor 	intolerable

2.5.65-bk		 56*
2.5.65-mm1		 <8	16	24
2.5.65-mm2		 <8	16	24
2.5.65-mm2 deadline	 <8	20	28

*2.5.65-bk was still performing very well at dbench 56.  I'll continue
to test up to 128 clients.

2.5.65-bk was updated with a bk pull this morning.

Steven

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.65-mm2

[Danny ter Haar]

Andrew Morton  <akpm@digeo.com> wrote:
>http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/
>. An update to the brlock-removal patches which might fix the reported
>  netfilter problems (would like confirmation of this please).

Yup, works again.
Where 2.5.64-mm7 & 2.5.65-mm1 didn't forward packets on my firewall.

Zanks !

Danny

-- 
Miguel   | "I can't tell if I have worked all my life or if
de Icaza |  I have never worked a single day of my life,"

Re: 2.5.65-mm2

[Alexander Hoogerhuis]

Andrew Morton <akpm@digeo.com> writes:
>
> [SNIP]
>

Yay! Still working Radeon :)

And 4x AGP:

agpgart: Putting AGP V2 device at 00:00.0 into 4x mode
agpgart: Putting AGP V2 device at 01:00.0 into 4x mode

Come to think of it, I'll give it a spin, this might be due to a
working DSDT table that was compiled in with ACPI, whereas I had the
1x problems before I did this.

mvh,
A
-- 
Alexander Hoogerhuis                               | alexh@ihatent.com
CCNP - CCDP - MCNE - CCSE                          | +47 908 21 485
"You have zero privacy anyway. Get over it."  --Scott McNealy

Re: 2.5.65-mm2

[Alexander Hoogerhuis]

Andrew Morton <akpm@digeo.com> writes:
>
> [SNIP]
>

Yay! Still working Radeon :)

And 4x AGP:

agpgart: Putting AGP V2 device at 00:00.0 into 4x mode
agpgart: Putting AGP V2 device at 01:00.0 into 4x mode

Come to think of it, I'll give it a spin, this might be due to a
working DSDT table that was compiled in with ACPI, whereas I had the
1x problems before I did this.

mvh,
A
-- 
Alexander Hoogerhuis                               | alexh@ihatent.com
CCNP - CCDP - MCNE - CCSE                          | +47 908 21 485
"You have zero privacy anyway. Get over it."  --Scott McNealy
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.65-mm2

[Alexander Hoogerhuis]

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

Andrew Morton <akpm@digeo.com> writes:
>
> [SNIP]
>

Heres a minor snag during depmod at installation of modules:

WARNING: /lib/modules/2.5.65-mm2/kernel/drivers/hotplug/acpiphp.ko needs unknown symbol acpi_resource_to_address64

It's been around a while. My .config is attached.

mvh,
A


[-- Attachment #2: .config --]
[-- Type: application/octet-stream, Size: 31950 bytes --]

#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# General setup
#
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_LOG_BUF_SHIFT=14

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MELAN is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_PREFETCH=y
CONFIG_X86_SSE2=y
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_EDD=y
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_05GB is not set
CONFIG_1GB=y
# CONFIG_2GB is not set
# CONFIG_3GB is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_SOFTWARE_SUSPEND is not set

#
# ACPI Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_PROC_INTF=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_24_API=y
CONFIG_CPU_FREQ_TABLE=y

#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=y
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
# CONFIG_X86_POWERNOW_K6 is not set
# CONFIG_X86_POWERNOW_K7 is not set
# CONFIG_X86_GX_SUSPMOD is not set
# CONFIG_X86_SPEEDSTEP is not set
CONFIG_X86_P4_CLOCKMOD=y
# CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_SCx200 is not set
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
CONFIG_HOTPLUG=y

#
# PCMCIA/CardBus support
#
CONFIG_PCMCIA=m
CONFIG_CARDBUS=y
# CONFIG_I82092 is not set
CONFIG_I82365=m
# CONFIG_TCIC is not set
CONFIG_PCMCIA_PROBE=y

#
# PCI Hotplug Support
#
CONFIG_HOTPLUG_PCI=m
CONFIG_HOTPLUG_PCI_COMPAQ=m
CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM=y
CONFIG_HOTPLUG_PCI_ACPI=m
CONFIG_HOTPLUG_PCI_CPCI=m
CONFIG_HOTPLUG_PCI_CPCI_ZT5550=m
CONFIG_HOTPLUG_PCI_CPCI_GENERIC=m

#
# Executable file formats
#
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m

#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=m
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_PARTITIONS=m
CONFIG_MTD_CONCAT=m
CONFIG_MTD_REDBOOT_PARTS=m
CONFIG_MTD_CMDLINE_PARTS=m

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=m
CONFIG_MTD_BLOCK=m
CONFIG_MTD_BLOCK_RO=m
CONFIG_FTL=m
CONFIG_NFTL=m
CONFIG_NFTL_RW=y

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=m
CONFIG_MTD_JEDECPROBE=m
CONFIG_MTD_GEN_PROBE=m
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_CFI_INTELEXT=m
CONFIG_MTD_CFI_AMDSTD=m
CONFIG_MTD_RAM=m
CONFIG_MTD_ROM=m
CONFIG_MTD_ABSENT=m
# CONFIG_MTD_OBSOLETE_CHIPS is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_PHYSMAP is not set
CONFIG_MTD_PNC2000=m
CONFIG_MTD_SC520CDP=m
CONFIG_MTD_NETSC520=m
CONFIG_MTD_SBC_GXX=m
CONFIG_MTD_ELAN_104NC=m
CONFIG_MTD_SCx200_DOCFLASH=m
CONFIG_MTD_PCI=m
CONFIG_MTD_PCMCIA=m
# CONFIG_MTD_UCLINUX is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
CONFIG_MTD_SLRAM=m
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLKMTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC1000 is not set
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set

#
# NAND Flash Device Drivers
#
CONFIG_MTD_NAND=m
CONFIG_MTD_NAND_ECC=y
CONFIG_MTD_NAND_VERIFY_WRITE=y

#
# Parallel port support
#
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_PC_CML1=m
CONFIG_PARPORT_SERIAL=m
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_PC_SUPERIO=y
CONFIG_PARPORT_PC_PCMCIA=m
CONFIG_PARPORT_OTHER=y
CONFIG_PARPORT_1284=y

#
# Plug and Play support
#
CONFIG_PNP=y
CONFIG_PNP_NAMES=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
CONFIG_ISAPNP=y
CONFIG_PNPBIOS=y

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_LBD=y

#
# ATA/ATAPI/MFM/RLL device support
#
CONFIG_IDE=y

#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_IDEDISK_STROKE=y
CONFIG_BLK_DEV_IDECS=m
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDEFLOPPY=m
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_IDE_TASK_IOCTL=y

#
# IDE chipset support/bugfixes
#
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDE_TCQ is not set
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_PCI_WIP is not set
CONFIG_BLK_DEV_ADMA=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_RZ1000 is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_BLK_DEV_IDE_MODES=y

#
# SCSI device support
#
CONFIG_SCSI=m

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
CONFIG_CHR_DEV_ST=m
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_REPORT_LUNS=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_MEGARAID is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_NCR53C7xx is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_NCR53C8XX is not set
# CONFIG_SCSI_SYM53C8XX is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_ISP_NEW is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_SEAGATE is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# PCMCIA SCSI adapter support
#
# CONFIG_PCMCIA_AHA152X is not set
# CONFIG_PCMCIA_FDOMAIN is not set
# CONFIG_PCMCIA_NINJA_SCSI is not set
# CONFIG_PCMCIA_QLOGIC is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_NET_KEY=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_INET_ECN=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_XFRM_USER=m

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_UNCLEAN=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_MIRROR=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_NAT_LOCAL=y
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_COMPAT_IPCHAINS=m
# CONFIG_IP_NF_COMPAT_IPFWADM is not set
CONFIG_IPV6=m
CONFIG_IPV6_PRIVACY=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m

#
# IPv6: Netfilter Configuration
#
CONFIG_IP6_NF_QUEUE=m
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_LIMIT=m
CONFIG_IP6_NF_MATCH_MAC=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_MULTIPORT=m
CONFIG_IP6_NF_MATCH_OWNER=m
CONFIG_IP6_NF_MATCH_MARK=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_AHESP=m
CONFIG_IP6_NF_MATCH_LENGTH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_MARK=m

#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IPV6_SCTP__=m
CONFIG_IP_SCTP=m
# CONFIG_SCTP_ADLER32 is not set
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_ATM is not set
CONFIG_VLAN_8021Q=m
# CONFIG_LLC is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_CSZ=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
CONFIG_NET_PKTGEN=m
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m
# CONFIG_ETHERTAP is not set
# CONFIG_NET_SB1000 is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_MII is not set
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
CONFIG_EEPRO100=m
# CONFIG_EEPRO100_PIO is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
# CONFIG_SLIP is not set

#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y

#
# Obsolete Wireless cards support (pre-802.11)
#
# CONFIG_STRIP is not set
# CONFIG_ARLAN is not set
# CONFIG_WAVELAN is not set
# CONFIG_PCMCIA_WAVELAN is not set
# CONFIG_PCMCIA_NETWAVE is not set

#
# Wireless 802.11 Frequency Hopping cards support
#
# CONFIG_PCMCIA_RAYCS is not set

#
# Wireless 802.11b ISA/PCI cards support
#
# CONFIG_AIRO is not set
CONFIG_HERMES=m
CONFIG_PLX_HERMES=m
CONFIG_PCI_HERMES=m

#
# Wireless 802.11b Pcmcia/Cardbus cards support
#
CONFIG_PCMCIA_HERMES=m
# CONFIG_AIRO_CS is not set
CONFIG_NET_WIRELESS=y

#
# Token Ring devices (depends on LLC=y)
#
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
CONFIG_SHAPER=m

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# PCMCIA network device support
#
CONFIG_NET_PCMCIA=y
# CONFIG_PCMCIA_3C589 is not set
# CONFIG_PCMCIA_3C574 is not set
# CONFIG_PCMCIA_FMVJ18X is not set
# CONFIG_PCMCIA_PCNET is not set
# CONFIG_PCMCIA_NMCLAN is not set
# CONFIG_PCMCIA_SMC91C92 is not set
# CONFIG_PCMCIA_XIRC2PS is not set
# CONFIG_PCMCIA_AXNET is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
CONFIG_IRDA=m

#
# IrDA protocols
#
CONFIG_IRLAN=m
CONFIG_IRNET=m
CONFIG_IRCOMM=m
CONFIG_IRDA_ULTRA=y

#
# IrDA options
#
CONFIG_IRDA_CACHE_LAST_LSAP=y
CONFIG_IRDA_FAST_RR=y
# CONFIG_IRDA_DEBUG is not set

#
# Infrared-port device drivers
#

#
# SIR device drivers
#
CONFIG_IRTTY_SIR=m

#
# Dongle support
#
# CONFIG_DONGLE is not set

#
# Old SIR device drivers
#
# CONFIG_IRTTY_OLD is not set
# CONFIG_IRPORT_SIR is not set

#
# Old Serial dongle support
#
# CONFIG_DONGLE_OLD is not set

#
# FIR device drivers
#
# CONFIG_USB_IRDA is not set
CONFIG_NSC_FIR=m
# CONFIG_WINBOND_FIR is not set
# CONFIG_TOSHIBA_OLD is not set
# CONFIG_TOSHIBA_FIR is not set
# CONFIG_SMC_IRCC_FIR is not set
# CONFIG_ALI_FIR is not set
# CONFIG_VLSI_FIR is not set

#
# ISDN subsystem
#
# CONFIG_ISDN_BOOL is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=m
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
CONFIG_INPUT_UINPUT=m

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=m
CONFIG_SERIAL_8250_CS=m
CONFIG_SERIAL_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_MULTIPORT is not set
# CONFIG_SERIAL_8250_RSA is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=m
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_PRINTER=y
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_PHILIPSPAR=m
CONFIG_I2C_ELV=m
CONFIG_I2C_VELLEMAN=m
CONFIG_SCx200_ACB=m
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ELEKTOR=m
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_PROC=m

#
# I2C Hardware Sensors Mainboard support
#
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_PIIX4=m

#
# I2C Hardware Sensors Chip support
#
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_LM75=m

#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_QIC02_TAPE is not set

#
# IPMI
#
CONFIG_IPMI_HANDLER=m
CONFIG_IPMI_PANIC_EVENT=y
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_KCS=m
CONFIG_IPMI_WATCHDOG=m

#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_NOWAYOUT=y
CONFIG_SOFT_WATCHDOG=m
# CONFIG_WDT is not set
# CONFIG_WDTPCI is not set
# CONFIG_PCWATCHDOG is not set
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
CONFIG_I810_TCO=m
# CONFIG_MIXCOMWD is not set
# CONFIG_SCx200_WDT is not set
# CONFIG_60XX_WDT is not set
# CONFIG_W83877F_WDT is not set
# CONFIG_MACHZ_WDT is not set
# CONFIG_SC520_WDT is not set
# CONFIG_AMD7XX_TCO is not set
# CONFIG_ALIM7101_WDT is not set
# CONFIG_SC1200_WDT is not set
# CONFIG_WAFER_WDT is not set
# CONFIG_CPU5_WDT is not set
# CONFIG_HW_RANDOM is not set
CONFIG_NVRAM=m
CONFIG_RTC=m
CONFIG_GEN_RTC=m
CONFIG_GEN_RTC_X=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
# CONFIG_AGP3 is not set
CONFIG_AGP_INTEL=y
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_AMD_8151 is not set
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
CONFIG_DRM_RADEON=y
# CONFIG_DRM_I810 is not set
# CONFIG_DRM_I830 is not set
# CONFIG_DRM_MGA is not set

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
# CONFIG_MWAVE is not set
CONFIG_RAW_DRIVER=m
CONFIG_HANGCHECK_TIMER=m

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=m

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=m
CONFIG_UDF_FS=m

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_DEVFS_FS=y
CONFIG_DEVFS_MOUNT=y
# CONFIG_DEVFS_DEBUG is not set
CONFIG_DEVPTS_FS=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
CONFIG_JFFS2_FS=m
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_NAND=y
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V4=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_SMB_FS=m
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="iso-8859-15"
CONFIG_CIFS=m
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
# CONFIG_AFS_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_SMB_NLS=y
CONFIG_NLS=y

#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-15"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
CONFIG_NLS_CODEPAGE_865=m
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ISO8859_1=m
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m

#
# Graphics support
#
# CONFIG_FB is not set
# CONFIG_VIDEO_SELECT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTPAV=m
CONFIG_SND_SERIAL_U16550=m
CONFIG_SND_MPU401=m

#
# ISA devices
#
# CONFIG_SND_AD1816A is not set
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES968 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_WAVEFRONT is not set
# CONFIG_SND_ALS100 is not set
# CONFIG_SND_AZT2320 is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_DT019X is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_SGALAXY is not set

#
# PCI devices
#
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
CONFIG_SND_INTEL8X0=m
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set

#
# ALSA USB devices
#
CONFIG_SND_USB_AUDIO=m

#
# Open Sound System
#
CONFIG_SOUND_PRIME=m
# CONFIG_SOUND_BT878 is not set
# CONFIG_SOUND_CMPCI is not set
# CONFIG_SOUND_EMU10K1 is not set
# CONFIG_SOUND_FUSION is not set
# CONFIG_SOUND_CS4281 is not set
# CONFIG_SOUND_ES1370 is not set
# CONFIG_SOUND_ES1371 is not set
# CONFIG_SOUND_ESSSOLO1 is not set
# CONFIG_SOUND_MAESTRO is not set
# CONFIG_SOUND_MAESTRO3 is not set
CONFIG_SOUND_ICH=m
# CONFIG_SOUND_RME96XX is not set
# CONFIG_SOUND_SONICVIBES is not set
# CONFIG_SOUND_TRIDENT is not set
# CONFIG_SOUND_MSNDCLAS is not set
# CONFIG_SOUND_MSNDPIN is not set
# CONFIG_SOUND_VIA82CXXX is not set
# CONFIG_SOUND_OSS is not set
# CONFIG_SOUND_TVMIXER is not set

#
# USB support
#
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_BANDWIDTH=y
CONFIG_USB_DYNAMIC_MINORS=y

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_UHCI_HCD=y

#
# USB Device Class drivers
#
CONFIG_USB_AUDIO=m

#
# USB Bluetooth TTY can only be used with disabled Bluetooth subsystem
#
CONFIG_USB_MIDI=m
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_HP8200e is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set

#
# USB Human Interface Devices (HID)
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
CONFIG_HID_FF=y
CONFIG_HID_PID=y
CONFIG_LOGITECH_FF=y
CONFIG_THRUSTMASTER_FF=y
CONFIG_USB_HIDDEV=y

#
# USB HID Boot Protocol drivers
#
CONFIG_USB_KBD=y
CONFIG_USB_MOUSE=y
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_XPAD is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_SCANNER is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_HPUSBSCSI is not set

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set

#
# Video4Linux support is needed for USB Multimedia device support
#

#
# USB Network adaptors
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_CDCETHER is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
CONFIG_USB_USBNET=m

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
CONFIG_USB_SERIAL_VISOR=m
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
CONFIG_USB_SERIAL_PL2303=m
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OMNINET is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_TIGL is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_BRLVGER is not set
# CONFIG_USB_LCD is not set
CONFIG_USB_TEST=m

#
# Bluetooth support
#
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=m
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y

#
# Bluetooth device drivers
#
CONFIG_BT_HCIUSB=m
CONFIG_BT_USB_ZERO_PACKET=y
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIUART_BCSP_TXCRC=y
CONFIG_BT_HCIDTL1=m
CONFIG_BT_HCIBT3C=m
CONFIG_BT_HCIBLUECARD=m
CONFIG_BT_HCIBTUART=m
CONFIG_BT_HCIVHCI=m

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_SLAB is not set
# CONFIG_X86_REMOTE_DEBUG is not set
# CONFIG_DEBUG_IOVIRT is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_SPINLINE is not set
CONFIG_KALLSYMS=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_FRAME_POINTER=y

#
# Security options
#
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_CAPABILITIES=m
CONFIG_SECURITY_ROOTPLUG=m

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_TEST=m

#
# Library routines
#
CONFIG_CRC32=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_X86_BIOS_REBOOT=y

[-- Attachment #3: Type: text/plain, Size: 206 bytes --]


-- 
Alexander Hoogerhuis                               | alexh@ihatent.com
CCNP - CCDP - MCNE - CCSE                          | +47 908 21 485
"You have zero privacy anyway. Get over it."  --Scott McNealy

2.5.65-mm2

[Andrew Morton]

http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/

will appear sometime at:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.65/2.5.65-mm2/


. Added all the 32-bit dev_t patches.

. An update to the brlock-removal patches which might fix the reported
  netfilter problems (would like confirmation of this please).



Changes since 2.5.65-mm1:


+linus.patch

 Latest from Linus

-noirqbalance-fix.patch
-ppc64-64-bit-exec-fix.patch
-remove-unused-congestion-stuff.patch
-smalldevfs.patch
-timer-cleanup.patch
-timer-readdition-fix.patch
-set_current_state-fs.patch
-set_current_state-mm.patch
-copy_thread-leak-fix.patch
-file_list_lock-contention-fix.patch
-tty_files-fixes.patch
-file_list_cleanup.patch
-file_list-remove-free_list.patch
-file-list-less-locking.patch
-vt_ioctl-stack-use.patch
-no-mmu-stubs.patch
-nommu-slab.patch
-nfs-memleak-fix.patch
-ufs-memleak-fix.patch
-posix-timers-update.patch
-oops-counters.patch
-io_apic-DO_ACTION-cleanup.patch
-oprofile-timer-fix.patch
-pgd_index-comments.patch
-proc-sysrq-trigger.patch
-CONFIG_NUMA-fixes.patch
-nfsd-symlink-failpath.patch
-get_disk-error-checking.patch
-nanosleep-accuracy-fix.patch

 Merged

+as-predict-data-direction.patch

 Anticipatory scheduler work: starting to track per-process behaviour a
 little more.

-brlock-removal-1.patch
+brlock-1b.patch

 Updated (might fix a netfilter problem)

+nanosleep-accuracy-fix-2.patch

 Another go at fixing the nanosleep() inaccuracy.

+linear-oops-fix-1.patch

 Fix oops in the MD linear driver

+dev_t-1-kill-cdev.patch
+dev_t-2-remove-MAX_CHRDEV.patch
+dev_t-3-major_h-cleanup.patch
+dev_t-32-bit.patch
+dev_t-drm-warnings.patch
+dev_t-remove-B_FREE.patch

 32-bit dev_t work

+cpufreq-xtime-locking.patch

 locking fix

+cs46xx-fixes.patch

 Minor fixes

+notsclock-option.patch

 Add "notsclock" boot option for misbehaving SpeedStep machines.

+tty-put_user-checks.patch

 Fix some missing uaccess checks.

+fail-setup_irq-for-unconfigured-IRQs.patch

 Stuff from Zwane.

+raw-fix-address_space-rewriting.patch
+raw-cleanups-and-fixlets.patch

 Fixes for the raw driver

+oops-dump-preceding-code.patch

 Make the ia32 oops code dump instructions which preceded the failing EIP. 
 Keith has ksymoops support for this and it works nicely.  I'm not sure what
 his plans are for adding it to a released version.



All 105 patches:

linus.patch
  Latest from Linus

mm.patch
  add -mmN to EXTRAVERSION

kgdb.patch

kgdb-cleanup.patch
  make kgdb less invasive (when disabled)

proc-sys-debug.patch
  create /proc/sys/debug/0 ... 7

config_spinline.patch
  uninline spinlocks for profiling accuracy.

ppc64-reloc_hide.patch

ppc64-pci-patch.patch
  Subject: pci patch

ppc64-aio-32bit-emulation.patch
  32/64bit emulation for aio

ppc64-scruffiness.patch
  Fix some PPC64 compile warnings

sym-do-160.patch
  make the SYM driver do 160 MB/sec

config-PAGE_OFFSET.patch
  Configurable kenrel/user memory split

ptrace-flush.patch
  cache flushing in the ptrace code

buffer-debug.patch
  buffer.c debugging

warn-null-wakeup.patch

ext3-truncate-ordered-pages.patch
  ext3: explicitly free truncated pages

reiserfs_file_write-5.patch

tcp-wakeups.patch
  Use fast wakeups in TCP/IPV4

rcu-stats.patch
  RCU statistics reporting

ext3-journalled-data-assertion-fix.patch
  Remove incorrect assertion from ext3

nfs-speedup.patch

nfs-oom-fix.patch
  nfs oom fix

sk-allocation.patch
  Subject: Re: nfs oom

nfs-more-oom-fix.patch

rpciod-atomic-allocations.patch
  Make rcpiod use atomic allocations

linux-isp.patch

isp-update-1.patch

kblockd.patch
  Create `kblockd' workqueue

as-iosched.patch
  anticipatory I/O scheduler

as-debug-BUG-fix.patch

as-eject-BUG-fix.patch
  AS: don't go BUG during cdrom eject

as-jumbo-fix.patch
  AS: OSDL fixes

as-request_fn-in-timer.patch
  Remove the scheduled_work thing

as-remove-request-fix.patch

as-np-1.patch
  as: cleanups & comments

as-use-kblockd.patch

as-cleanup-2.patch
  AS: cleanup + comments

as-as_remove_request-simplification.patch
  as: as_remove_request simplification

as-dont-go-BUG-again.patch

as-handle-non-block-requests.patch
  AS: handle non-block requests

as-np-reads-1.patch
  AS: read-vs-read fixes

as-np-reads-2.patch
  AS: more read-vs-read fixes

as-predict-data-direction.patch
  as: predict direction of next IO

cfq-2.patch
  CFQ scheduler, #2

unplug-use-kblockd.patch
  Use kblockd for running request queues

remap-file-pages-2.5.63-a1.patch
  Subject: [patch] remap-file-pages-2.5.63-A1

hugh-remap-fix.patch
  hugh's file-offset-in-pte fix

fremap-limit-offsets.patch
  fremap: limit remap_file_pages() file offsets

fremap-all-mappings.patch
  Make all executable mappings be nonlinear

filemap_populate-speedup.patch
  filemap_populate speedup

file-offset-in-pte-x86_64.patch
  x86_64: support for file offsets in pte's

file-offset-in-pte-ppc64.patch

objrmap-2.5.62-5.patch
  object-based rmap

objrmap-nonlinear-fixes.patch
  objrmap fix for nonlinear

sched-2.5.64-D3.patch
  sched-2.5.64-D3, more interactivity changes

scheduler-tunables.patch
  scheduler tunables

show_task-free-stack-fix.patch
  show_task() fix and cleanup

yellowfin-set_bit-fix.patch
  yellowfin driver set_bit fix

htree-nfs-fix.patch
  Fix ext3 htree / NFS compatibility problems

update_atime-ng.patch
  inode a/c/mtime modification speedup

one-sec-times.patch
  Implement a/c/time speedup in ext2 & ext3

task_prio-fix.patch
  simple task_prio() fix

slab_store_user-large-objects.patch
  slab debug: perform redzoning against larger objects

pcmcia-2.patch

pcmcia-3b.patch

pcmcia-3.patch

pcmcia-4.patch

pcmcia-5.patch

pcmcia-6.patch

pcmcia-7b.patch

pcmcia-7.patch

pcmcia-8.patch

pcmcia-9.patch

pcmcia-10.patch

htree-nfs-fix-2.patch
  htree nfs fix

ext2-no-lock_super.patch
  concurrent block allocation for ext2

ext2-ialloc-no-lock_super.patch
  concurrent inode allocation for ext2

brlock-1b.patch
  Re: 2.5.64-mm8 breaks MASQ

brlock-removal-2.patch
  brlock removal 2/5: remove brlock from snap and vlan

brlock-removal-3.patch
  brlock removal 3/5: remove brlock from bridge

brlock-removal-4.patch
  brlock removal 4/5: removal from ipv4/ipv6

brlock-removal-5.patch
  brlock removal 5/5: remove brlock code

lseek-ext2_readdir.patch
  remove lock_kernel() from readdir implementations.

inode_setattr-lock_kernel-removal.patch
  remove lock_kernel() from inode_setattr's vmtruncate() call

ide_probe-init_irq-fix.patch
  ide-probe init_irq cleanup

raid1-fix.patch
  MD RAID1 fix

nmi-watchdog-fix.patch
  NMI watchdog fix

vm_enough_memory-speedup.patch
  speed up vm_enough_memory()

nanosleep-accuracy-fix-2.patch
  fix nanosleep() granularity bumps

linear-oops-fix-1.patch
  md/linear oops fix

dev_t-1-kill-cdev.patch
  dev_t [1/3]: kill cdev

dev_t-2-remove-MAX_CHRDEV.patch
  dev_t [2/3] - remove MAX_CHRDEV

dev_t-3-major_h-cleanup.patch
  dev_t [3/3]: major.h cleanups

dev_t-32-bit.patch
  [for playing only] change type of dev_t

dev_t-drm-warnings.patch
  dev_t: fix drm printk warnings

dev_t-remove-B_FREE.patch
  dev_t: eliminate B_FREE

smalldevfs.patch
  smalldevfs

cpufreq-xtime-locking.patch
  add write_seqlock to cpufreq change notifier for TSC

cs46xx-fixes.patch
  cs46xx minor fixes

notsclock-option.patch
  boot time parameter to turn of TSC usage

tty-put_user-checks.patch
  Add missing put_user checks in n_tty

fail-setup_irq-for-unconfigured-IRQs.patch
  Fail setup_irq for unconfigured IRQs

raw-fix-address_space-rewriting.patch
  raw driver: rewrite i_mapping only on final close

raw-cleanups-and-fixlets.patch
  raw driver: cleanups and small fixes

oops-dump-preceding-code.patch
  i386 oops output: dump preceding code

2.5.65-mm2

[Andrew Morton]

http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/

will appear sometime at:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.65/2.5.65-mm2/


. Added all the 32-bit dev_t patches.

. An update to the brlock-removal patches which might fix the reported
  netfilter problems (would like confirmation of this please).



Changes since 2.5.65-mm1:


+linus.patch

 Latest from Linus

-noirqbalance-fix.patch
-ppc64-64-bit-exec-fix.patch
-remove-unused-congestion-stuff.patch
-smalldevfs.patch
-timer-cleanup.patch
-timer-readdition-fix.patch
-set_current_state-fs.patch
-set_current_state-mm.patch
-copy_thread-leak-fix.patch
-file_list_lock-contention-fix.patch
-tty_files-fixes.patch
-file_list_cleanup.patch
-file_list-remove-free_list.patch
-file-list-less-locking.patch
-vt_ioctl-stack-use.patch
-no-mmu-stubs.patch
-nommu-slab.patch
-nfs-memleak-fix.patch
-ufs-memleak-fix.patch
-posix-timers-update.patch
-oops-counters.patch
-io_apic-DO_ACTION-cleanup.patch
-oprofile-timer-fix.patch
-pgd_index-comments.patch
-proc-sysrq-trigger.patch
-CONFIG_NUMA-fixes.patch
-nfsd-symlink-failpath.patch
-get_disk-error-checking.patch
-nanosleep-accuracy-fix.patch

 Merged

+as-predict-data-direction.patch

 Anticipatory scheduler work: starting to track per-process behaviour a
 little more.

-brlock-removal-1.patch
+brlock-1b.patch

 Updated (might fix a netfilter problem)

+nanosleep-accuracy-fix-2.patch

 Another go at fixing the nanosleep() inaccuracy.

+linear-oops-fix-1.patch

 Fix oops in the MD linear driver

+dev_t-1-kill-cdev.patch
+dev_t-2-remove-MAX_CHRDEV.patch
+dev_t-3-major_h-cleanup.patch
+dev_t-32-bit.patch
+dev_t-drm-warnings.patch
+dev_t-remove-B_FREE.patch

 32-bit dev_t work

+cpufreq-xtime-locking.patch

 locking fix

+cs46xx-fixes.patch

 Minor fixes

+notsclock-option.patch

 Add "notsclock" boot option for misbehaving SpeedStep machines.

+tty-put_user-checks.patch

 Fix some missing uaccess checks.

+fail-setup_irq-for-unconfigured-IRQs.patch

 Stuff from Zwane.

+raw-fix-address_space-rewriting.patch
+raw-cleanups-and-fixlets.patch

 Fixes for the raw driver

+oops-dump-preceding-code.patch

 Make the ia32 oops code dump instructions which preceded the failing EIP. 
 Keith has ksymoops support for this and it works nicely.  I'm not sure what
 his plans are for adding it to a released version.



All 105 patches:

linus.patch
  Latest from Linus

mm.patch
  add -mmN to EXTRAVERSION

kgdb.patch

kgdb-cleanup.patch
  make kgdb less invasive (when disabled)

proc-sys-debug.patch
  create /proc/sys/debug/0 ... 7

config_spinline.patch
  uninline spinlocks for profiling accuracy.

ppc64-reloc_hide.patch

ppc64-pci-patch.patch
  Subject: pci patch

ppc64-aio-32bit-emulation.patch
  32/64bit emulation for aio

ppc64-scruffiness.patch
  Fix some PPC64 compile warnings

sym-do-160.patch
  make the SYM driver do 160 MB/sec

config-PAGE_OFFSET.patch
  Configurable kenrel/user memory split

ptrace-flush.patch
  cache flushing in the ptrace code

buffer-debug.patch
  buffer.c debugging

warn-null-wakeup.patch

ext3-truncate-ordered-pages.patch
  ext3: explicitly free truncated pages

reiserfs_file_write-5.patch

tcp-wakeups.patch
  Use fast wakeups in TCP/IPV4

rcu-stats.patch
  RCU statistics reporting

ext3-journalled-data-assertion-fix.patch
  Remove incorrect assertion from ext3

nfs-speedup.patch

nfs-oom-fix.patch
  nfs oom fix

sk-allocation.patch
  Subject: Re: nfs oom

nfs-more-oom-fix.patch

rpciod-atomic-allocations.patch
  Make rcpiod use atomic allocations

linux-isp.patch

isp-update-1.patch

kblockd.patch
  Create `kblockd' workqueue

as-iosched.patch
  anticipatory I/O scheduler

as-debug-BUG-fix.patch

as-eject-BUG-fix.patch
  AS: don't go BUG during cdrom eject

as-jumbo-fix.patch
  AS: OSDL fixes

as-request_fn-in-timer.patch
  Remove the scheduled_work thing

as-remove-request-fix.patch

as-np-1.patch
  as: cleanups & comments

as-use-kblockd.patch

as-cleanup-2.patch
  AS: cleanup + comments

as-as_remove_request-simplification.patch
  as: as_remove_request simplification

as-dont-go-BUG-again.patch

as-handle-non-block-requests.patch
  AS: handle non-block requests

as-np-reads-1.patch
  AS: read-vs-read fixes

as-np-reads-2.patch
  AS: more read-vs-read fixes

as-predict-data-direction.patch
  as: predict direction of next IO

cfq-2.patch
  CFQ scheduler, #2

unplug-use-kblockd.patch
  Use kblockd for running request queues

remap-file-pages-2.5.63-a1.patch
  Subject: [patch] remap-file-pages-2.5.63-A1

hugh-remap-fix.patch
  hugh's file-offset-in-pte fix

fremap-limit-offsets.patch
  fremap: limit remap_file_pages() file offsets

fremap-all-mappings.patch
  Make all executable mappings be nonlinear

filemap_populate-speedup.patch
  filemap_populate speedup

file-offset-in-pte-x86_64.patch
  x86_64: support for file offsets in pte's

file-offset-in-pte-ppc64.patch

objrmap-2.5.62-5.patch
  object-based rmap

objrmap-nonlinear-fixes.patch
  objrmap fix for nonlinear

sched-2.5.64-D3.patch
  sched-2.5.64-D3, more interactivity changes

scheduler-tunables.patch
  scheduler tunables

show_task-free-stack-fix.patch
  show_task() fix and cleanup

yellowfin-set_bit-fix.patch
  yellowfin driver set_bit fix

htree-nfs-fix.patch
  Fix ext3 htree / NFS compatibility problems

update_atime-ng.patch
  inode a/c/mtime modification speedup

one-sec-times.patch
  Implement a/c/time speedup in ext2 & ext3

task_prio-fix.patch
  simple task_prio() fix

slab_store_user-large-objects.patch
  slab debug: perform redzoning against larger objects

pcmcia-2.patch

pcmcia-3b.patch

pcmcia-3.patch

pcmcia-4.patch

pcmcia-5.patch

pcmcia-6.patch

pcmcia-7b.patch

pcmcia-7.patch

pcmcia-8.patch

pcmcia-9.patch

pcmcia-10.patch

htree-nfs-fix-2.patch
  htree nfs fix

ext2-no-lock_super.patch
  concurrent block allocation for ext2

ext2-ialloc-no-lock_super.patch
  concurrent inode allocation for ext2

brlock-1b.patch
  Re: 2.5.64-mm8 breaks MASQ

brlock-removal-2.patch
  brlock removal 2/5: remove brlock from snap and vlan

brlock-removal-3.patch
  brlock removal 3/5: remove brlock from bridge

brlock-removal-4.patch
  brlock removal 4/5: removal from ipv4/ipv6

brlock-removal-5.patch
  brlock removal 5/5: remove brlock code

lseek-ext2_readdir.patch
  remove lock_kernel() from readdir implementations.

inode_setattr-lock_kernel-removal.patch
  remove lock_kernel() from inode_setattr's vmtruncate() call

ide_probe-init_irq-fix.patch
  ide-probe init_irq cleanup

raid1-fix.patch
  MD RAID1 fix

nmi-watchdog-fix.patch
  NMI watchdog fix

vm_enough_memory-speedup.patch
  speed up vm_enough_memory()

nanosleep-accuracy-fix-2.patch
  fix nanosleep() granularity bumps

linear-oops-fix-1.patch
  md/linear oops fix

dev_t-1-kill-cdev.patch
  dev_t [1/3]: kill cdev

dev_t-2-remove-MAX_CHRDEV.patch
  dev_t [2/3] - remove MAX_CHRDEV

dev_t-3-major_h-cleanup.patch
  dev_t [3/3]: major.h cleanups

dev_t-32-bit.patch
  [for playing only] change type of dev_t

dev_t-drm-warnings.patch
  dev_t: fix drm printk warnings

dev_t-remove-B_FREE.patch
  dev_t: eliminate B_FREE

smalldevfs.patch
  smalldevfs

cpufreq-xtime-locking.patch
  add write_seqlock to cpufreq change notifier for TSC

cs46xx-fixes.patch
  cs46xx minor fixes

notsclock-option.patch
  boot time parameter to turn of TSC usage

tty-put_user-checks.patch
  Add missing put_user checks in n_tty

fail-setup_irq-for-unconfigured-IRQs.patch
  Fail setup_irq for unconfigured IRQs

raw-fix-address_space-rewriting.patch
  raw driver: rewrite i_mapping only on final close

raw-cleanups-and-fixlets.patch
  raw driver: cleanups and small fixes

oops-dump-preceding-code.patch
  i386 oops output: dump preceding code



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>