With a lot of help from Nick Piggin and Zwane Mwaikambo I've synced my smtnice patch with 2.6.3-mm4. It was quite a bit more effort than the original patch was but is built on better foundations. It shouldn't be too hard to expand on this for newer SMT designs now. I don't think it's in the final shape it will be in just yet but is working nicely.
Linus released 2.6.4-rc1 and I had some time to resync -ck with it. I've put all the patches that are going into 2.6.4-ck1 into my experimental dir:
http://ck.kolivas.org/patches/2.6/2.6.4/experimental/
This includes all the fixes I've been working on, and the new separating of the smt nice work so I can merge it with Nick's sched domains. When 2.6.4 is released I'll have a standalone smt nice patch (it is smtbase4 + smtnice4) for those that are using this without my other patches (is there anyone?).
Read a not bad article over at 2cpu.com where they did some benchmarking on hyperthreading on linux. http://www.2cpu.com/articles/ht_linux/ I threw a few comments their way about the limitations of the benchmarks they did.
Posted a miniscule fix for the smt nice patch in my experimental directory.
Had a semantics discussion about whether vm_swappiness should be #ifdef'ed out completely for the non CONFIG_SWAP case. Probably makes no difference but looks uglier with lots of ifdefs so I think I'll just put one ifdef that removes a compiler warning.
I finally got jack of going to bed with tinnitus (buzzing eardrums) from listening to cpu and case fans. In a complete turnaround I suddenly can't stand any noise from my machine and have been doing heaps of research on effective quiet cooling solutions for my box. I needed something that allows me to run my distributed computing client mprime or mpeg2 encoding flat out without my cpu getting too hot or my hearing from dying.
Rik (last name unknown but not Riel) has been silently sending me patches while I've been maintaining the 2.4 patchset and has been kind enough to fix the bootsplash patch so it works with my 2.6 patchset. I've thrown his incremental bootsplash patch in my experimental directory for testing:
Bugfix update. I'll be putting it up very soon here:
Finally I managed to quash that bug that would cause an oops on smp if spawning a batch process. It's now much less flaky at last! Just as I was about to give up hope on this problem and make batch scheduling less smart I found the problem. Now I can open a console as sched_batch and that makes all things spawned from that console batch scheduled. Good for mpeg2encoding, filtering and so on.
Resynced with 2.6.3
Lots of little improvements but no new features.
Merged bootsplash but my machine failed to boot so I haven't included it by default. Other people have had it working ok. It's possibly an SMP issue.
Started signing the patches as requested.
OSDL got back to me with some hardware for testing smp kernels. As promised to them I started hacking together a benchmark based on MBligh's kernbench. I got some feedback from Martin on what he thought it needs and I've modified it to suit. It seems to be working nicely now. I'll wait for Martin to get back to me about this version and assuming all is well I'll announce it on lkml and get the osdl people to add it to their choice of benchmarks.
Resynced with 2.6.2. All these Australian animals in the kernels made me decide to do this sooner rather than later ;). Added supermount-ng, tweaked some patches and updated the FAQ. Jens keeps promising me a new cfq and ioprio patch soon but I can always release a new version when he does. Nick's VM pressure stuff looks worth merging too but it's a bit of work since he works from -mm and I'm feeling lazy at the moment. Posted to lkml...
Ok now that I've tested 2.6.1-ck3 on a few machines for it's stability and safety I figure it's time to release it publicly. I've updated my website with details now and I'll announce it to lkml.
Here goes my first full -ck patch for 2.6. I think I'll just silently put it up on my website and here in this blog. Works for me ;-)
While considering the "nice" problem on hyperthread cpus and the disadvantages of my first attempt at a hyperthread "nice" patch I came up with a much better solution. Instead of arbitrarily choosing a priority difference for when things won't run I let them run for their appropriate timeslice relative to the sibling's task's timeslice. This one works beautifully and I've posted it to lkml.
I updated the vm_swappiness autoregulation. It takes into account swap memory now by putting a ceiling on the vm_swappiness as it fills up based on the last (sizeof physical ram) of swap space. Tiny tweaks to the code as well; small optimisation and change in the maths to support massive ram. I moved that out of the experimental directory.
I've downloaded the latest schedtools (0.98) and modified it slightly to have direct support for SCHED_ISO now and put the tarball onto my website:
I have the "isochronous" scheduling patch working now. Any task trying to start as real time that doesn't have authority to do so will be set to SCHED_ISO. This is a non-expiring scheduler policy designed to guarantee a timeslice within a reasonable latency while preventing starvation. Good for gaming, video at the limits of hardware, video capture etc. It is best set using the schedtool by a normal user trying to start something as SCHED_RR.