Announcement

Collapse
No announcement yet.

Con Kolivas Contemplates Ending Kernel Development, Retiring MuQSS & -ck Patches

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • pal666
    replied
    Originally posted by avem View Post
    I'm not skilled enough to comment on anything Torvalds says
    he listed number of valid reasons
    Originally posted by avem View Post
    but the way I see it, you choose a scheduler on boot and that's it. Does it matter what data structures it operates with when those are not used by anything else or are they?
    they at least take space(grep for "cache footprint" in torvalds quote) and to chose you have to do indirection(grep for "indirect pointers" again). and it complicates code, which is also a downside(it's hard for people to work with complicated code)

    Leave a comment:


  • pal666
    replied
    Originally posted by avem View Post
    This has been discussed here on Phoronix in-depth.
    it's very unauthoritative source
    Originally posted by avem View Post
    I'm not a kernel hacker but again from what I've heard from experienced programmers
    not everyone who claims to be experienced programmer is worth listening to
    Originally posted by avem View Post
    here, in Reddit and on Hacker News there are no technical reasons or obstacles in mainlining his code. Someone in the mailing list objected to the very idea of being able to switch process schedulers on boot
    which is a technical reason
    Originally posted by avem View Post
    (I guess it's not that difficult to do it even at runtime - after all the kernel is perfectly able to suspend and resume all running processes).
    it's difficult to do it without making other things worse

    Leave a comment:


  • pal666
    replied
    while your patches are out of tree, you have to maintain them yourself. that doesn't scale

    Leave a comment:


  • pal666
    replied
    Originally posted by avem View Post
    The kernel developers by turning your efforts down have made it abundantly clear that your open source work and effort are not welcome.
    do you know, that maintainer's main job is to say no? otherwise you'll get software full of shit
    Originally posted by avem View Post
    Technically there have been zero reasons not to mainline your code.
    technically patches have to pass review. every developer knows it
    Last edited by pal666; 31 August 2021, 04:16 PM.

    Leave a comment:


  • avem
    replied
    Originally posted by F.Ultra View Post

    If you are not going to accept Linus:es reasons then you are not going to accept any one elses. If we continue to quote Linus from the 2007 thread about pluggable schedulers:
    It's great that everyone here quotes Torvalds exclusively but you know in any conflict there are two sides and no one has posted anything by Con Kolivas as if there's just his scheduler created out of nowhere with no one behind it. Also, it looks like folks here strongly imply Torvalds is infallible.

    I'm not skilled enough to comment on anything Torvalds says but the way I see it, you choose a scheduler on boot and that's it. Does it matter what data structures it operates with when those are not used by anything else or are they?

    Leave a comment:


  • F.Ultra
    replied
    Originally posted by avem View Post

    We already have multiple IO schedulers. Please find a reason why we can't have multiple process schedulers.
    If you are not going to accept Linus:es reasons then you are not going to accept any one elses. If we continue to quote Linus from the 2007 thread about pluggable schedulers:
    Go wild. It's what open-source is all about. I'm not stopping you. I'm just not merging code that makes the scheduler unreadable, even hard to understand, and slows things down. I'm also not merging code that sets some scheduler policy limits by having specific "pluggable scheduler interfaces". Different schedulers tend to need different data structures in some *very* core data, like the per-cpu run-queues, in "struct task_struct", in "struct thread_struct" etc etc. Those are some of *the* most low-level structures in the kernel. And those are things that get set up to have as little cache footprint a possible etc. IO schedulers have basically none of those issues. Once you need to do IO, you'll happibly use a few indirect pointers, it's not going to show up anywhere. But in the scheduler, 10 cycles here and there will be a big deal. And hey, you can try to prove me wrong. Code talks. So far, nobody has really ever come close. So go and code it up, and show the end result. So far, nobody who actually *does* CPU schedulers have really wanted to do it, because they all want to muck around with their own private versions of the data structures.

    Leave a comment:


  • tomas
    replied
    Originally posted by avem View Post

    We already have multiple IO schedulers. Please find a reason why we can't have multiple process schedulers.
    The continuation of Linus's first post reads:
    ​​​​​​
    And CPU scheduling really isn't that complicated. It's *way* simpler than IO scheduling. There simply is *no*excuse* for not trying to do it well enough for all cases, or for having special-case stuff. But even IO scheduling actually ends up being largely the same. Yes, we have pluggable schedulers, and we even allow switching them, but in the end, we don't want people to actually do it. It's much better to have a scheduler that is "good enough" than it is to have five that are "perfect" for five particular cases.
    Source:
    ​​​​https://lore.kernel.org/lkml/Pine.LN...oundation.org/
    Last edited by tomas; 31 August 2021, 01:19 PM.

    Leave a comment:


  • royce
    replied
    Sad day. I used CK patched kernels way back when kernel 2.4 or maybe 2.6 and I was using gentoo and compiling absolutely everything on my system and really getting into the meat of Linux in general.

    Best of luck to Mr Kolivas.

    Leave a comment:


  • Vistaus
    replied
    I won't be sad about this. Tried -ck a few times, but everything felt slower than normal. Xanmod still has the best kernel IMHO.

    Leave a comment:


  • avem
    replied
    Originally posted by waxhead View Post

    Incorrect. Where do you think "A decade of wasted cores" come from? ref.: https://www.phoronix.com/scan.php?pa...-Scheduler-Bad
    One might just as easily argue that If there is one solution and that behaves sub-optimally on hardware 'xyz' or workload 'abc' more people are likely to be fed up and do something about it.
    We already have multiple IO schedulers. Please find a reason why we can't have multiple process schedulers.

    Leave a comment:

Working...
X