Announcement

Collapse
No announcement yet.

More Patches To Improve Linux Desktop Responsiveness

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

  • #11
    reminding of this (xkcd)

    this patchset might be the missing puzzle-piece for "smooth full-screen flash video"

    I haven't tested full-screen flash yet

    another important part is that Adobe implements video-acceleration

    perhaps the easiest would be to use openGL ES 2.0 ? (I don't know if that even would work)

    Comment


    • #12
      ok, HD video seems to work fine (beautifully), too

      in fullscreen with new catalyst 10.8 and almost no GPU load

      try the following video *click*

      make sure you select 720p

      you might need to force hardware acceleration:

      Originally posted by /etc/adobe/mms.cfg
      #
      # /etc/adobe/mms.cfg: Adobe Flash privacy and security settings
      #
      # For more details on the meaning of most of these options, please visit:
      # http://www.adobe.com/devnet/flashpla...min_guide.html
      #

      # Lets you prevent users from designating any files on the local file system as
      # trusted
      # 0 = Not Allowed, 1 = Allowed (default)
      #AllowUserLocalTrust = 1

      # Lets you specify a hard limit on the amount of local storage that Flash Player
      # uses for the storage of common Flash components
      # Size in megabytes (default is 20), 0 = Component storage disabled
      #AssetCacheSize = 20

      # Lets you prevent Flash Player from automatically checkingfor and installing
      # updated versions
      # 0 = Not Disabled (default), 1 = Disabled
      AutoUpdateDisable = 1

      # Lets you specify how often to check for an updated version of Flash Player
      # Number of days, 0 = Every startup
      # There is no default value, which falls back to the user's setting (30 days by
      # default)
      #AutoUpdateInterval =

      # Lets you prevent SWF files from accessing webcams or microphones
      # 0 = Not Disabled (default), 1 = Disabled
      AVHardwareDisable = 1

      # Lets you prevent information on installed fonts from being displayed
      # 0 = Not Disabled (default), 1 = Disabled
      #DisableDeviceFontEnumeration = 0

      # Lets you prevent networking or file system access if any kind
      # Set to the executable filename, default is empty
      #DisableNetworkAndFilesystemInHostApp =

      # Lets you prevent native code applications that are digitally signed and
      # delivered by Adobe from being downloaded
      # 0 = Not Disabled (default), 1 = Disabled
      #DisableProductDownload = 0

      # Lets you enable or disable the use of the Socket.connect() and
      # XMLSocket.connect() methods
      # 0 = Not Disabled (default), 1 = Disabled
      #DisableSockets = 0

      # Lets you create a whitelist of servers to which socket connections are allowed
      # Set to hostname or IP address. This can be specified multiple times in this
      # file to allow more than one host, and only takes effect if DisableSockets
      # (above) is set to 1.
      #EnableSocketsTo = localhost.localdomain
      #EnableSocketsTo = 127.0.0.1

      # Lets you prevent the ActionScript FileReference API from performing file
      # downloads
      # 0 = Not Disabled (default), 1 = Disabled
      #FileDownloadDisable = 0

      # Lets you prevent the ActionScript FileReference API from prerforming file
      # uploads
      # 0 = Not Disabled (default), 1 = Disabled
      #FileUploadDisable = 0

      # Lets you disable SWF files playing via a browser plug-in from being displayed
      # in full-screen mode
      # 0 = Not Disabled (default), 1 = Disabled
      #FullScreenDisable = 0

      # Lets you specify whether SWF files produced for Flash Player 6 and earlier can
      # execute an operation that has been restricted in a newer version of Flash
      # Player
      # 0 = Deny, 1 = Allow
      # There is no default value, which falls back to the user's setting (Defaults to
      # "Ask"
      #LegacyDomainMatching =

      # Lets you specify how Flash Player should determine whether to execute certain
      # local SWF files that were originally produced for Flash Player 7 and earlier
      # 0 = Deny, 1 = Allow
      # There is no default value, which falls back to the user's setting
      #LocalFileLegacyAction =

      # Lets you prevent local SWF files from having read access to files on local
      # drive
      # 0 = Not Disabled (default), 1 = Disabled
      #LocalFileReadDisable = 0

      # Lets you specify a hard limit on the amout of local storage that Flash Player
      # uses (per domain) for persistent shared objects
      # 1 = no storage, 2 = 10KB, 3 = 100KB, 4 = 1MB, 5 = 10MB,
      # 6 = User specified (default)
      # If the user does not specify a limit, the default is 100KB.
      #LocalStorageLimit = 6

      # Lets you override GPU validation checks to force hardware acceleration
      # Warning: This may make your player (more) unstable!
      # 0 = Check GPU (default), 1 = Skip checks
      # More details:
      # http://blogs.adobe.com/penguin.swf/2...fg_file_1.html
      OverrideGPUValidation = 1

      # Lets you specify whether third-party SWF files can read and write locally
      # persistent shared objects
      # 0 = disabled, 1 = enabled
      # There is no default value, which falls back to the user's setting
      #ThirdPartyStorage =

      # Lets you disable "Windowless" mode, which may cause crashes in firefox
      # version 3.01 and earlier.
      # 0 = Not Disabled (default), 1 = Disabled
      # More details:
      # http://blogs.adobe.com/penguin.swf/2..._mode_fix.html
      #WindowlessDisable = 0

      Comment


      • #13
        Originally posted by kernelOfTruth View Post
        reminding of this (xkcd)

        this patchset might be the missing puzzle-piece for "smooth full-screen flash video"
        Smooth full-screen Flash video works here just fine with open display drivers on an ATi card. Just takes 32bit Adobe Flash on a 32bit Firefox.

        Comment


        • #14
          ps. Fine, that video takes a lot of CPU in 720p but not enough to use even a single full core on E8500 and definitely not enough to make it kick the CPU fan on more rotations.

          Comment


          • #15
            That video works perfectly fine and fluid in 720p fullscreen here with open source radeon driver and BFS scheduler :P

            Comment


            • #16
              What impact will these patches have on throughput for servers that don't require instantaneous response times? Will there be a way to disable these patches for servers if they are merged into mainline?

              I don't know about this patchset in particular, but frequently, responsiveness issues are a direct tradeoff with throughput and efficiency. The efficiency side: For better responsiveness, the CPU has to be awake a lot, constantly processing events to make things "respond" as quickly as possible. The throughput side: Aside from scheduler thrashing issues that may interfere with processes' ability to get a consistent stream of work done, the other problem with most responsiveness patches is that it creates a lot of overhead in terms of context switches, cache flushes, and IPIs. This can reduce the amount of operations per second that can be performed on the CPU.

              So for servers, you want to line up as many bowling pins as you can, and then bowl a strike, even if it takes you time to line them up. For desktops, you want to throw down one pin, sprint back, grab the bowling ball, hit that one pin, and repeat. Although you can probably set up and hit one pin faster than you can set up 12 or 24 pins and hit them, you've hit less pins in that time than you could have. Hence the throughput vs responsiveness issue.

              I've seen a great many VFS, virtual memory/allocator, and scheduler patches hit mainline in the past year, and sometimes I worry that it's just some guy with a hammer trying to find something that looks like a nail. Phoronix has noted that most kernel releases bring only regressions for typical systems, not improvements. How long have we been sliding down the performance slope, and how far will we keep sliding until everyone is happy?

              I'm all for configurability, though. If there's a patch that has a tradeoff, merge it to mainline and add a config option. We could always use more config options. It warms the Gentoo user's heart, and for the rest of us, it gives the distro kernel maintainers something useful to do, like set the proper options for the desktop vs. server kernels.

              So in closing, if this patch is universally either beneficial or a wash regardless of whether you're in a desktop or server environment, I say merge it without an option. But if we find that it comes with added overhead and reduced throughput for servers, it shouldn't be merged unless it can be made configurable, at least with a Y/N if a module doesn't make sense.

              Comment


              • #17
                Originally posted by allquixotic View Post
                What impact will these patches have on throughput for servers that don't require instantaneous response times? Will there be a way to disable these patches for servers if they are merged into mainline?

                I don't know about this patchset in particular, but frequently, responsiveness issues are a direct tradeoff with throughput and efficiency. The efficiency side: For better responsiveness, the CPU has to be awake a lot, constantly processing events to make things "respond" as quickly as possible. The throughput side: Aside from scheduler thrashing issues that may interfere with processes' ability to get a consistent stream of work done, the other problem with most responsiveness patches is that it creates a lot of overhead in terms of context switches, cache flushes, and IPIs. This can reduce the amount of operations per second that can be performed on the CPU.

                So for servers, you want to line up as many bowling pins as you can, and then bowl a strike, even if it takes you time to line them up. For desktops, you want to throw down one pin, sprint back, grab the bowling ball, hit that one pin, and repeat. Although you can probably set up and hit one pin faster than you can set up 12 or 24 pins and hit them, you've hit less pins in that time than you could have. Hence the throughput vs responsiveness issue.

                I've seen a great many VFS, virtual memory/allocator, and scheduler patches hit mainline in the past year, and sometimes I worry that it's just some guy with a hammer trying to find something that looks like a nail. Phoronix has noted that most kernel releases bring only regressions for typical systems, not improvements. How long have we been sliding down the performance slope, and how far will we keep sliding until everyone is happy?

                I'm all for configurability, though. If there's a patch that has a tradeoff, merge it to mainline and add a config option. We could always use more config options. It warms the Gentoo user's heart, and for the rest of us, it gives the distro kernel maintainers something useful to do, like set the proper options for the desktop vs. server kernels.

                So in closing, if this patch is universally either beneficial or a wash regardless of whether you're in a desktop or server environment, I say merge it without an option. But if we find that it comes with added overhead and reduced throughput for servers, it shouldn't be merged unless it can be made configurable, at least with a Y/N if a module doesn't make sense.
                there probably won't be any if you haven't enabled those features via the debugfs

                so far I've noticed a significant delay when trying to launch applications during heavy (CPU) load and rattling of the hdd so throughput may go down at the cost of interactivity

                someone should do some benchmarks - another job for PTS !

                Comment


                • #18
                  Originally posted by allquixotic View Post
                  What impact will these patches have on throughput for servers that don't require instantaneous response times? Will there be a way to disable these patches for servers if they are merged into mainline?
                  It seems no one pays attention. These patches were introduced in order to improve performance on server load. Linus Torvalds complained that it damaged desktop performance. So this is round two of those patches: improving server performance while not hurting desktop performance.

                  I don't get why everyone, including Michael, claims these are desktop improvement patches in the first place. Which is why I don't trust this whole thing, since I care only about desktop issues... Too much misinformation and no real explanation at what these patches do.

                  Comment


                  • #19
                    Originally posted by unimatrix View Post
                    Finally! There should be more effort put into the desktop responsiveness. It's the one problem that gives new Linux users that feel of "slowness".
                    The problem are graphic drivers and/or related things. Others are probably nearly meaningless compared to causes of 'slowness' related to graphic.

                    Comment


                    • #20
                      Originally posted by nanonyme View Post
                      Smooth full-screen Flash video works here just fine with open display drivers on an ATi card. Just takes 32bit Adobe Flash on a 32bit Firefox.
                      The same here, but with 32bit flash and 64bit Firefox. Top shows CPU load 110% (Athlon X2 5000+), kwin compositions enabled, 2.6.32 kernel and git version of open source radeon driver from Ubuntu ppa.

                      Comment

                      Working...
                      X