Tuesday, 29 March 2011

2.6.38-ck1, BFS 0.363

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.

13 comments:

  1. 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.

    Anyway backed down to ck1 patch for now until things settle down with ck2 patch.

    Thanks for the kernel goodies!

    ReplyDelete
  2. 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.

    I'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.

    ReplyDelete
  3. I would much rather you do the work you do, with the very, very occasional "flip-flop" than not have your excellent work.

    Keep up the good work.

    ReplyDelete
  4. 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...

    ReplyDelete
  5. Thanks 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.

    ReplyDelete
  6. With 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.

    As the Linux kernel development seems to have slowed down there might be a new window of again to propose a scheduler plugin infrastructure ?

    ReplyDelete
  7. 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.

    patching 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

    ReplyDelete
  8. This comment has been removed by the author.

    ReplyDelete
  9. I read in the faq

    "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) :)

    ReplyDelete
  10. That's still a good summary of my position. Thanks ponce, and you're welcome.

    ReplyDelete
  11. Hi,

    Just 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

    ReplyDelete
  12. 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.

    ReplyDelete
  13. I know 2.6.38 vanilla works fine, I'll try to compile some stuff myself to nail this one. Thanks,

    ReplyDelete