Announcement

Collapse
No announcement yet.

The v2 Rotary Interactivity Favor Scheduler

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

  • Originally posted by kernelOfTruth View Post
    did some data backup and at the same time used the opportunity to watch 1080p video + 2 sound streams (including the hd video's stream)

    at least 5-10 times it stopped for 1-2 seconds


    observations so far:

    1) there seem to be issues with the sound system (probably pulseaudio related)

    would renice hep ?

    2) with heavy writing + HD video it lags pretty much - so there's issues with i/o, I'm already using BFQ but seemingly there's still room for improvements

    3) amd64: there seems to be more issues with heavy i/o (see the amd64 gentoo subforum on forums.gentoo.org)


    so I'll see during the next days on regular / everyday usage how it goes


    will at earliest be able to compare in a week with the non-ES



    impression so far: it only might be a feeling but the non-ES RIFS felt a little more fluid, dunno (especially when comparing the total halt of sound + video of HD video streaming - weird, gotta check next time if the video-streaming stopped or if it really was due to heavy i/o)


    thanks !
    Yeah, it is caused by the sleep tracking.
    So here I have posted the no-sleep-tracking version
    https://rifs-scheduler.googlecode.co...ec-kernel3.4.x

    and benchmark are done with non-sleep-tracking version
    https://rifs-scheduler.googlecode.co...Result-002.PNG

    Thanks for reporting this(sleep-tracking broken)
    CHEN

    Comment


    • Originally posted by kernelOfTruth View Post
      man, that's impressive to say the least


      BFS & CFS linearly "scale" for worse latency and RIFS-ES (already better) after 60-70 clients gets better and better with more and more clients

      fascinating !


      no idea about scheduling but there's surely some way to improve it even more (interestingly it scales similarly like BFS up to 50 and then between 55 - around 72 it's worse but then gets significantly better - might this be an issue
      with parts from mainline ? - you're partly using stuff from mainline - right ?)

      [I'm referring to Result-001.PNG, "Benchmark between RIFS-ES, CFS, BFS(latt, 64-200 clients)"]



      oh - kudos where kudos are due:

      http://phoronix.com/forums/showthrea...duler-Released



      I'll get around in about a week to test it again under very heavy load

      thanks !
      More benchmark with RIFS-ES(Low Spec), CFS, BFS:
      http://code.google.com/p/rifs-schedu...Result-003.PNG

      RIFS-ES-Low-Spec has been posted.

      Comment


      • Originally posted by 3766691 View Post
        More benchmark with RIFS-ES(Low Spec), CFS, BFS:
        http://code.google.com/p/rifs-schedu...Result-003.PNG

        RIFS-ES-Low-Spec has been posted.
        nice


        I believe I know what is causing trouble for me: it's pulseaudio !

        it seems that is a real PITA when running 2 streams (I started this week listening to two and more streams - I love mixing) and htop shows between 100-300% cpu load - which is ridiculous btw


        that not only affects fluidity of video playback but also overall smoothness & fluidity of my composited desktop (compiz-fusion) - argh !


        the system is still smooth but it's at least noticable that the cpu is kept busy ...

        Comment


        • Originally posted by kernelOfTruth View Post
          nice


          I believe I know what is causing trouble for me: it's pulseaudio !

          it seems that is a real PITA when running 2 streams (I started this week listening to two and more streams - I love mixing) and htop shows between 100-300% cpu load - which is ridiculous btw


          that not only affects fluidity of video playback but also overall smoothness & fluidity of my composited desktop (compiz-fusion) - argh !


          the system is still smooth but it's at least noticable that the cpu is kept busy ...
          So if RIFS-ES-LOW-SPEC could help you to make the system responsive.
          Anyway many people.complain about the unresponsive problem about RIFS-ES and many people like RIFS-ES-LOW-SPEC, so RIFS-ES-LOW-SPEC would become the offical version of RIFS-ES
          RIFS will still be kept, it is used to make comparsion

          Comment


          • Originally posted by 3766691 View Post
            So if RIFS-ES-LOW-SPEC could help you to make the system responsive.
            Anyway many people.complain about the unresponsive problem about RIFS-ES and many people like RIFS-ES-LOW-SPEC, so RIFS-ES-LOW-SPEC would become the offical version of RIFS-ES
            RIFS will still be kept, it is used to make comparsion
            actually my system just got very un-responsive (even worse than BFS or CFS !) while playing 2 streams (I use it while studying & relaxing), backing up data (ext4 -> ext4 on luks partitions) and having around 10-20 okular instances open,

            20-30 tabs in chromium, 2-4 tabs in firefox, 4-6 tabs in nautilus, xfce4 desktop with compiz-fusion


            and this was only while rsyncing the whole partition (around 1.3 TB)

            afaik this didn't happen that extreme in the past - with CFS there were small stops of sound but then it immediately countinued (0.5 - 2 seconds), this was only with 1 audio stream so far

            it can't be that the 2nd stream causes that much trouble

            swap is using around 1.6 GB, RAM is used up around 6 GB of 8

            vfs_cache_pressure around 50, swappiness 60





            I'll try using the original (v2 ?) implementation without lowres of RIFS (which worked best for me so far) and see whether that improves things - hopefully it does since I really need the box 1000% available right now



            Chen, you think this could be several issues ? (some more tweaks needed in RIFS, major issues in sound, ata, graphics, etc. subsystems ?)

            thanks !



            edit:

            ok, tweaked the cpu governor a bit - let's see how it goes


            edit2:

            it's not even only under heavy i/o

            not it's all the time

            it seems some apps are constantly keeping the cpu / scheduler busy

            and load is around 2-3 - weird :/


            I definitely have to try out the non-ES RIFS scheduler and compare
            Last edited by kernelOfTruth; 06-22-2012, 02:33 PM.

            Comment


            • lol - something nasty is going on:


              [40851.104643] BUG: Bad rss-counter state mm:ffff880230e2bb80 idx:1 val:-2
              [40851.104648] BUG: Bad rss-counter state mm:ffff880230e2bb80 idx:2 val:2
              [41915.438826] BUG: Bad rss-counter state mm:ffff8802350c8000 idx:1 val:-1
              [41915.438834] BUG: Bad rss-counter state mm:ffff8802350c8000 idx:2 val:1
              [41915.440299] BUG: Bad rss-counter state mm:ffff880231aa1f80 idx:1 val:-1
              [41915.440307] BUG: Bad rss-counter state mm:ffff880231aa1f80 idx:2 val:1
              [41915.440454] BUG: Bad rss-counter state mm:ffff8802223a6c80 idx:1 val:-1
              [41915.440459] BUG: Bad rss-counter state mm:ffff8802223a6c80 idx:2 val:1
              [41915.442346] BUG: Bad rss-counter state mm:ffff8802351b0380 idx:1 val:-1
              [41915.442352] BUG: Bad rss-counter state mm:ffff8802351b0380 idx:2 val:1
              [41915.593699] BUG: Bad rss-counter state mm:ffff880184a08380 idx:1 val:-1
              [41915.593704] BUG: Bad rss-counter state mm:ffff880184a08380 idx:2 val:1
              [41915.607687] BUG: Bad rss-counter state mm:ffff8801842e6580 idx:1 val:-2
              [41915.607692] BUG: Bad rss-counter state mm:ffff8801842e6580 idx:2 val:2
              [41915.617876] BUG: Bad rss-counter state mm:ffff8801842e5400 idx:1 val:-2
              [41915.617880] BUG: Bad rss-counter state mm:ffff8801842e5400 idx:2 val:2
              [41915.621546] BUG: Bad rss-counter state mm:ffff8801842e4600 idx:1 val:-1
              [41915.621550] BUG: Bad rss-counter state mm:ffff8801842e4600 idx:2 val:1
              [41915.621988] BUG: Bad rss-counter state mm:ffff880184a0ec80 idx:1 val:-2
              [41915.621992] BUG: Bad rss-counter state mm:ffff880184a0ec80 idx:2 val:2
              [41915.622856] BUG: Bad rss-counter state mm:ffff8801842e5b00 idx:1 val:-1
              [41915.622860] BUG: Bad rss-counter state mm:ffff8801842e5b00 idx:2 val:1
              [41915.651114] BUG: Bad rss-counter state mm:ffff8802351e2680 idx:1 val:-2
              [41915.651118] BUG: Bad rss-counter state mm:ffff8802351e2680 idx:2 val:2
              [41915.652672] BUG: Bad rss-counter state mm:ffff8802351e5400 idx:1 val:-2
              [41915.652677] BUG: Bad rss-counter state mm:ffff8802351e5400 idx:2 val:2
              [41915.655617] BUG: Bad rss-counter state mm:ffff8801842e2300 idx:1 val:-1
              [41915.655621] BUG: Bad rss-counter state mm:ffff8801842e2300 idx:2 val:1
              [41915.660228] BUG: Bad rss-counter state mm:ffff8802351e3b80 idx:1 val:-1
              [41915.660231] BUG: Bad rss-counter state mm:ffff8802351e3b80 idx:2 val:1
              [41915.662536] BUG: Bad rss-counter state mm:ffff8801842e0a80 idx:1 val:-1
              [41915.662540] BUG: Bad rss-counter state mm:ffff8801842e0a80 idx:2 val:1
              [41915.728599] BUG: Bad rss-counter state mm:ffff880235277380 idx:1 val:-2
              [41915.728602] BUG: Bad rss-counter state mm:ffff880235277380 idx:2 val:2
              [41922.881771] BUG: Bad rss-counter state mm:ffff8802223a3b80 idx:1 val:-1
              [41922.881777] BUG: Bad rss-counter state mm:ffff8802223a3b80 idx:2 val:1
              [41924.393537] BUG: Bad rss-counter state mm:ffff8802351e0700 idx:1 val:-2
              [41924.393543] BUG: Bad rss-counter state mm:ffff8802351e0700 idx:2 val:2
              [41925.418184] BUG: Bad rss-counter state mm:ffff8802223a7a80 idx:1 val:-1
              [41925.418190] BUG: Bad rss-counter state mm:ffff8802223a7a80 idx:2 val:1
              [41925.419895] BUG: Bad rss-counter state mm:ffff8802223a5e80 idx:1 val:-1
              [41925.419902] BUG: Bad rss-counter state mm:ffff8802223a5e80 idx:2 val:1
              [41926.007780] BUG: Bad rss-counter state mm:ffff8801842e2a00 idx:1 val:-1
              [41926.007788] BUG: Bad rss-counter state mm:ffff8801842e2a00 idx:2 val:1
              [41926.012419] BUG: Bad rss-counter state mm:ffff880184a0db00 idx:1 val:-1
              [41926.012427] BUG: Bad rss-counter state mm:ffff880184a0db00 idx:2 val:1
              [41926.015712] BUG: Bad rss-counter state mm:ffff880184a0a680 idx:1 val:-1
              [41926.015722] BUG: Bad rss-counter state mm:ffff880184a0a680 idx:2 val:1
              [41926.045152] BUG: Bad rss-counter state mm:ffff880230e29f80 idx:1 val:-1
              [41926.045158] BUG: Bad rss-counter state mm:ffff880230e29f80 idx:2 val:1
              [41926.092410] BUG: Bad rss-counter state mm:ffff8801842e1180 idx:1 val:-1
              [41926.092415] BUG: Bad rss-counter state mm:ffff8801842e1180 idx:2 val:1

              I'll tweak dirty ratios, swap, etc. and see how it goes

              actually it shouldn't be necessary but in this case there's no other way since I need the box


              thanks !

              Comment


              • the kernel with rifs-v2-bugfix2-kernel3.4.x went through without a glitch - well, almost:

                there were small glitches for 1/2 to 1/4 second but it was better than CFS and BFS in my opinion


                which means that the prior rifs shows more consistent behavior


                the new RIFS-ES isn't that consistent (can also be seen with the jumps in the graphics you posted), don't know what's the reason or how to improve on that ...


                anyway I'll stay with the mentioned patch for now - it seems to be quite reliable - not that smooth like RIFS-ES but it stays on the same level over time, it seems


                thanks !

                Comment


                • Originally posted by kernelOfTruth View Post
                  the kernel with rifs-v2-bugfix2-kernel3.4.x went through without a glitch - well, almost:

                  there were small glitches for 1/2 to 1/4 second but it was better than CFS and BFS in my opinion


                  which means that the prior rifs shows more consistent behavior


                  the new RIFS-ES isn't that consistent (can also be seen with the jumps in the graphics you posted), don't know what's the reason or how to improve on that ...


                  anyway I'll stay with the mentioned patch for now - it seems to be quite reliable - not that smooth like RIFS-ES but it stays on the same level over time, it seems


                  thanks !
                  I will try to work on it. If RIFS-ES-Low-Spec is even worse than RIFS-ES I will throw -ES(Bad design?)

                  Edit 2
                  Hi which one of RIFS-ES-Low-Spec it is? It looks like that it is the problem of the 3.5.x one.
                  Last edited by 3766691; 06-22-2012, 04:11 PM.

                  Comment


                  • Originally posted by 3766691 View Post
                    I will try to work on it. If RIFS-ES-Low-Spec is even worse than RIFS-ES I will throw -ES(Bad design?)

                    Edit 2
                    Hi which one of RIFS-ES-Low-Spec it is? It looks like that it is the problem of the 3.5.x one.
                    the one I used was:

                    RIFS.ES-v1-low-spec-kernel3.4.x


                    RIFS.ES (the first one) had some issues as far as I know, like you wrote and afaik I and others also experienced some small issues - so I'm currently using rifs-v2-bugfix2-kernel3.4.x
                    Last edited by kernelOfTruth; 06-22-2012, 04:19 PM.

                    Comment


                    • Originally posted by kernelOfTruth View Post
                      the one I used was:

                      RIFS.ES-v1-low-spec-kernel3.4.x
                      It seems like that it has different performance. On my box and other users feedback they said the desktop is very smooth.
                      So could you post your config? thanks!
                      The option I need is Tickless, HZ, Preemption model.
                      It is necessary to disable the Tickless because Tickless can cause big latency and RIFS doesn't work well with variable timer interrupt HZ.

                      Comment


                      • sure:

                        http://pastebin.com/gaUv52Ue (valid 1 month)

                        Comment


                        • Originally posted by kernelOfTruth View Post
                          sure:

                          http://pastebin.com/gaUv52Ue (valid 1 month)
                          CONFIG_NO_HZ=y

                          Could you turn it off and re-compile the kernel ?
                          Thanks.

                          As I say
                          The algorithm of RIFS-ES can be affected by variable clock interrupt.

                          Comment


                          • Originally posted by 3766691 View Post
                            CONFIG_NO_HZ=y

                            Could you turn it off and re-compile the kernel ?
                            Thanks.

                            As I say
                            The algorithm of RIFS-ES can be affected by variable clock interrupt.

                            sure, will do

                            I read that there isn't that much of more power consumption:

                            http://www.phoronix.com/scan.php?pag...item=651&num=1


                            where others claim 10-20% more consumption:

                            http://ubuntuforums.org/archive/index.php/t-524694.html


                            now raw performance and efficiency counts (in terms of workflow) so I'll revert to tickless or more energy-friendly settings in 1-2 weeks ^^

                            Comment


                            • well, that massively helped

                              pulseaudio now continually seems to stay at 1% cpu load instead of pegging around 100-300%


                              it could have been partly an issue caused by configuration but I believe it's partly also due to tickless:

                              Originally posted by diff config-3.4-geek_rifs_v2 config-3.4-geek_RIFS_ES-no-tickless_less-debug
                              3c3
                              < # Linux/x86_64 3.4.2-geek Kernel Configuration
                              ---
                              > # Linux/x86_64 3.4.2-geek_btrfs+_libata_RIFS-ES-v1-low-spec Kernel Configuration
                              113d112
                              < CONFIG_RCU_FAST_NO_HZ=y
                              319c318
                              < CONFIG_NO_HZ=y
                              ---
                              > # CONFIG_NO_HZ is not set
                              326a326
                              > CONFIG_SCHED_OMIT_FRAME_POINTER=y
                              553d552
                              < CONFIG_CPU_IDLE_GOV_MENU=y
                              2113a2113
                              > # CONFIG_NTP_PPS is not set
                              3754,3755c3754
                              < CONFIG_UNWIND_INFO=y
                              < CONFIG_STACK_UNWIND=y
                              ---
                              > # CONFIG_UNWIND_INFO is not set
                              3759c3758
                              < CONFIG_RCU_CPU_STALL_VERBOSE=y
                              ---
                              > # CONFIG_RCU_CPU_STALL_VERBOSE is not set

                              it's still for 1-2 seconds stalling when it's heavily writing even though the dirty values are low as "1" - but that obviously might be caused by either luks/device-mapper or the filesystems and the other subsystems (VFS, writeback, etc.) involved


                              last kernel that - in my opinion - had really great writeback performance was 2.6.34, dunno


                              will stay on this kernel now ...


                              thanks !
                              Last edited by kernelOfTruth; 06-23-2012, 05:38 AM.

                              Comment


                              • Originally posted by kernelOfTruth View Post
                                sure, will do

                                I read that there isn't that much of more power consumption:

                                http://www.phoronix.com/scan.php?pag...item=651&num=1


                                where others claim 10-20% more consumption:

                                http://ubuntuforums.org/archive/index.php/t-524694.html


                                now raw performance and efficiency counts (in terms of workflow) so I'll revert to tickless or more energy-friendly settings in 1-2 weeks ^^
                                It seems that Tickless just help very little on power saving. On the other hand using tickless system can cause significantly high latency

                                Comment

                                Working...
                                X