2.4.20-ck5 sucks

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi

Thanks for all the feedback I've gotten from people.

It seems the interactivity patch wasn't worth the effort, confirming my suspicions - which is why I resisted posting it in the first place.

I've made ck4 available again on my website.

I've updated the split out patches to a pre-ck6 state without the interactivity patches.

Rmap15f is now available also.

http://kernel.kolivas.org

Con

P.S. My new motto - if it sucks, let me know.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+l4aoF6dfvkL3i1gRAiEVAJ4vRs2YzmWVSUP9VtaczwPd037ExwCgh7rO 1/kq4QDKMFosbIogp5D308w=
=vwxz
-----END PGP SIGNATURE-----

Yikes! I've been indulging in 2.5.67 + anticipatory I/O for bit now, back to 2.4...

I finally got around running ck5 with a lot of other odd patches from here and there just last night. I wasn't sure if it was ck5 or any thing else I put in my kernel that caused it, but the scheduler didn't seem to want to work once physical memory was low.

There's a pretty serious bug in the ck5 scheduler where things stop running after physical memory is low. Even if the make World jobs are cancelled, performance is still sluggish.

I tried compiling X in two directories simultaneously, 2.5.67+as-I/O passes with flying colors while remaining quite usable in X. ck5 works initially, but once I started using up memory the CPU started idling (even though there was plenty of CPU work to be done) and eventually everything stalled :(

I started looking at the 2.5.66/7 scheduler again and did a glorified cut and paste job that seems to work, at least with regards to fixing performance system deteriorating and not recovering syndrome.

It's not tuned for the best interactive response yet, HZ is unchanged from the 2.4 default of 100, and heavy disk I/O still kills latency (I didn't run the read latency2 hack). Nevertheless, XMMS plays SHN/FLAC/mp3 files well even during large compile jobs, even while limiting myself to only 128M of physical RAM.

this patch is against 001_o1_pe_ll_030412_ck_2.4.20 only

note: not SMP tested!

diff -ruNp ck6pre/include/linux/sched.h ck5bad/include/linux/sched.h
@@ -355,7 +355,7 @@ struct task_struct {
 	prio_array_t *array;
 
 	unsigned long sleep_avg;
-	unsigned long sleep_timestamp;
+	unsigned long last_run;
 
 	unsigned long policy;
 	unsigned long cpus_allowed;

diff -ruNp ck6pre/kernel/fork.c ck5bad/kernel/fork.c
@@ -733,7 +733,7 @@ int do_fork(unsigned long clone_flags, u
 		current->time_slice = 1;
 		scheduler_tick(0,0);
 	}
-	p->sleep_timestamp = jiffies;
+	p->last_run = jiffies;
 	__sti();
 
 	/*

Eric Wong

<---snip-->

Eric I appreciate the work you've done for ck5, but this is two discrete problems.

The first is the one you describe with the memory killing the scheduler - a serious bug.

The second is that the interactivity patch is too slow. It takes up to 5 seconds for xmms skipping (the reference bad program but used everywhere) to stop. When you first start music it skips all over the place and then settles down after a while. This is embarassing considering the machines are >1Ghz cpus and it doesnt happen on p233 with old scheduler. It appears to take less time the higher the Hz is (makes sense I guess) however higher Hz in 2.4 incurs too much overhead under heavy load. This happens even in 2.5 but is a bit more subtle.

My concern is that ck6pre without the interactivity addon works better. I've added the more finegrained scheduler timing and the small bugfix but backed out the rest. I don't think the interactivity patch in it's current form is of any use to O(1) 2.4 kernels.

I think Zwane and others have demonstrated that this happens in 2.5 as well so it needs some work yet to be better than stock.

Con