Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 42

Thread: More Patches To Improve Linux Desktop Responsiveness

  1. #11
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    640

    Default

    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)

  2. #12
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    640

    Default

    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:

    Quote 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

  3. #13
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,670

    Default

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

  4. #14
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,670

    Default

    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.

  5. #15
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,798

    Default

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

  6. #16
    Join Date
    Sep 2008
    Posts
    989

    Default

    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.

  7. #17
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    640

    Default

    Quote 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 !

  8. #18
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,798

    Default

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

  9. #19

    Default

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

  10. #20

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •