Announcement

Collapse
No announcement yet.

Intel Posts Big Linux Patch Set For "Classes of Tasks" On Hybrid CPUs, Thread Director

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

  • #31
    Originally posted by birdie View Post

    Looks like it. Won't comment on your previous post since I'm in a very rough spot right now and I can't really think. I'm about to become handicapped and it's really hard to accept and live through it.
    Seriously, what do You mean by that, Artem?

    Becoming handicapped is one of the things I'm actually scared of in life...

    Really hope You will be fine!

    Comment


    • #32
      Originally posted by Linuxxx View Post

      Seriously, what do You mean by that, Artem?

      Becoming handicapped is one of the things I'm actually scared of in life...

      Really hope You will be fine!
      Torn meniscus, cyst, pain in the knee, unable to walk, stuff like this. For some reasons our knees (and other joints) are very fragile and very hard or often impossible to fix/cure. I'd be OK to deal with something like this if I were a sportsman, did some crazy stuff, or I were past 50 or obese, but no, nothing like that. I'm normally only walking and swimming for a week once a year.
      Last edited by birdie; 14 September 2022, 03:19 AM.

      Comment


      • #33
        Originally posted by NobodyXu View Post
        Android has been using heterogeneous core for a long time and I did not find any userspace scheduler.
        The most recent effort I found is "Energy Aware Scheduling" https://www.kernel.org/doc/html/late...ed-energy.html
        I can't find a good source for what it does to the CPU scheduler, but Android has an extensive userspace process priority thing. Most of the documentation centers around app killing under memory pressure (h/t atomsymbol​'s point about mathematical representation of performance to developers) , but circumstantial evidience suggests it uses the utilization clamping feature to "manage" the behavior of the CPU frequency governor.

        Comment


        • #34
          Originally posted by yump View Post

          I can't find a good source for what it does to the CPU scheduler, but Android has an extensive userspace process priority thing. Most of the documentation centers around app killing under memory pressure (h/t atomsymbol​'s point about mathematical representation of performance to developers) , but circumstantial evidience suggests it uses the utilization clamping feature to "manage" the behavior of the CPU frequency governor.
          Thank you very much for the information!

          Comment


          • #35
            Originally posted by birdie View Post
            Torn meniscus, cyst, pain in the knee, unable to walk, stuff like this.
            If there's *excessive* pain, find a decent pain specialist and investigate a CRPS diagnosis immediately. The success rate for treatment drops sharply after ~3 months, and continues to plummet after that. Since it's literally the worst pain known to man you very much do not want to end up there, and early intervention is crucial if you develop it.

            Comment


            • #36
              Originally posted by NobodyXu View Post
              >> Lastly, the Linux kernel does not allow the user to raise the priority of the task once it's been decreased which makes things even more complicated.

              That's not true.
              Sorry, but it is. If you nice a process down, you cannot even restore it *to its original priority*, other than via root/sudo privs. It's an absurd bug that should have been fixed decades ago. The reasoning behind not allowing it is "sensible", but that doesn't make it any less broken.

              Comment


              • #37
                Originally posted by arQon View Post

                Sorry, but it is. If you nice a process down, you cannot even restore it *to its original priority*, other than via root/sudo privs. It's an absurd bug that should have been fixed decades ago. The reasoning behind not allowing it is "sensible", but that doesn't make it any less broken.
                Linux actually has RLIMIT_NICE​ which could support this, but most distro just set it to 0...

                Comment


                • #38
                  Originally posted by NobodyXu View Post
                  Linux actually has RLIMIT_NICE​ which could support this, but most distro just set it to 0...
                  Thanks, but I'm already painfully aware of this, because I have use cases (especially on Pi-tier HW) where I need renice to, you know, *actually work properly*.

                  Developers and users have a right to expect their OS to behave in a sane manner. Being unable to reset the priority of a process to the same priority it was started with is unquestionably *not* sane, and it prohibits several key use cases from being possible at all, let alone readily viable. The suggestion that every distro should have to work around it just to arrive at a correctly-functional system is, by definition, an indicator that the behavior is fundamentally broken.

                  Which it is, though like I say it was for "good" reasons at the time, since the alternative was an exploit. What we ideally need though is for the bug to be fixed properly, so that the exploit stays gone but the rest of the behavior becomes correct. The "cost" of that though is an extra int in the process struct, so instead we got this terrible hack.

                  Comment


                  • #39
                    Originally posted by arQon View Post

                    Thanks, but I'm already painfully aware of this, because I have use cases (especially on Pi-tier HW) where I need renice to, you know, *actually work properly*.

                    Developers and users have a right to expect their OS to behave in a sane manner. Being unable to reset the priority of a process to the same priority it was started with is unquestionably *not* sane, and it prohibits several key use cases from being possible at all, let alone readily viable. The suggestion that every distro should have to work around it just to arrive at a correctly-functional system is, by definition, an indicator that the behavior is fundamentally broken.

                    Which it is, though like I say it was for "good" reasons at the time, since the alternative was an exploit. What we ideally need though is for the bug to be fixed properly, so that the exploit stays gone but the rest of the behavior becomes correct. The "cost" of that though is an extra int in the process struct, so instead we got this terrible hack.
                    Yes I think having a hard upper limit for nice (default to 0) is probably a good fix, but it seems nobody is motivated to submit a patch for it.

                    Comment


                    • #40
                      Originally posted by NobodyXu View Post
                      Yes I think having a hard upper limit for nice (default to 0) is probably a good fix, but it seems nobody is motivated to submit a patch for it.
                      IIRC the idea was shot down for the reason I mentioned, so there was no point to anyone providing one. It was a very long time ago though, and I don't trust my memory for anything that far back - these things tend to blur together as time goes by.

                      Comment

                      Working...
                      X