So I screwed up. Sorry!
BFS 370 causes some strange regressions as per this blog and offlist. It appears that F&H doesn't, for example, scale to multiple CPUs under BFS 370. Also some latency regressions were reported here (and elsewhere). So I've decided to pull BFS 370 and 2.6.38-ck2, pending further investigation. There's only so much I can do without lots of people testing, I'm afraid, and often I get 1 maybe 2 people testing before a "stable" release, and then get about 10,000 downloads once the stable release comes out. So it was with test2/BFS370. Anyway the point is, go back to 2.6.38-ck1 or BFS 363 till I figure out what the problem was and decide whether it's worth pursuing this avenue or not.
The same thing happens to me! I put packages in testing and no reports of problems but as soon as I move them to updates then all of a sudden there is some kind of problem.
ReplyDeleteAnyway backed down to ck1 patch for now until things settle down with ck2 patch.
Thanks for the kernel goodies!
hey ck, sorry not getting back to you sooner regarding the patch. The build got stuck on a bad builder, and it took a couple days to sort out.
ReplyDeleteI'm working on packaging for an Ubuntu ppa. I've been working on streamlining my packaging process so that I can push out patched packages much more quickly, and maybe get you some more testers!
Anyway, my test results for this patch were lackluster too. I was testing on the kraken benchmark, comparing conservative vs ondemand vs full speed. I didn't notice a whole lot of difference. With or without the patch I got about 15.5s for conservative, 21 for ondemand, and 14.5 for full speed.
I realize that we may be looking at different issues. I'm not knowledgeable enough to say. I cued in on the reference to frequency governors. I reported my issue to kernel.org and they came back with the tunable sampling_down_factor. It looks very promising for my issue. I've just started testing it. It might be of interest to you too.
I would much rather you do the work you do, with the very, very occasional "flip-flop" than not have your excellent work.
ReplyDeleteKeep up the good work.
Up today early testers only can test using their feelings or their hand touching the machine to feel the temperature. If we would have some easy tool to measure differences there would be lots more feedback for Con Kolivas! And surely more fun for testers to see results...
ReplyDeleteThanks guys, I appreciate the feedback. I'm very cautious with regards to releasing a dud kernel as the community easily turns when they have a bad experience.
ReplyDeleteWith linux-2.6.39_rc1 there is a comment from LT "nothing new". Also 2.6.38 I saw more as a point release of 2.6.37.
ReplyDeleteAs the Linux kernel development seems to have slowed down there might be a new window of again to propose a scheduler plugin infrastructure ?
Hello, i've edited your patch-2.6.35-ck1.tar.bz2 so it can be patch to 2.6.35.11 nicely. The only problem is when i applying mm-drop_swap_cache_aggressively.patchone.
ReplyDeletepatching file mm/memory.c
Hunk #1 succeeded at 2747 with fuzz 1.
I don't know how to fix it. It only replace one line. But the patch still apply correctly though. I am using (+ with bfq) the patchset now without any problem.
Link : http://www.mediafire.com/?9tvp3te7jydhf4m
This comment has been removed by the author.
ReplyDeleteI read in the faq
ReplyDelete"Are you looking at getting this into mainline?
LOL.
No really, are you?
LOL.
Really really, are you?
No."
thanks for all of your stuff (I use it since the Staircase Deadline to frag better) :)
That's still a good summary of my position. Thanks ponce, and you're welcome.
ReplyDeleteHi,
ReplyDeleteJust tried linux-image-2.6.38.2-ck1-2_2.6.38.2-ck1-2-10.00.Custom_amd64.deb on Ubuntu 10.10 / Lenovo T510. It doesn't boot, just spits out error messages, like these:
DRHD: handling fault status reg 3
DMAR:[DMA Read] Request Device [0d:00.0] fault addr fffff000
DMAR:[fault reason 02] Present bit in context entry is clear
DRHD: handling fault status reg 3
DMAR:[DMA Read] Request Device [0d:00.0] fault addr fffff000
DMAR:[fault reason 02] Present bit in context entry is clear
... and so on. Any ideas? lspci -vvv here:
http://pastebin.com/SpX6vj7r
Hmm no idea, sorry. You'd have to compare it to a 2.6.38.2 kernel from elsewhere to see whether the problem is in -ck, my package, or 2.6.38. You could always try the 2.6.35.11 package instead. 2.6.38. is still pretty new.
ReplyDeleteI know 2.6.38 vanilla works fine, I'll try to compile some stuff myself to nail this one. Thanks,
ReplyDelete