I'm running the latest zen kernel, and the kill_machine program still does manage to kill my machine if there's any swap... If there's none (swapoff -a) it just hangs it for a few seconds before it's killed for running out of ram. It seems to me like swap isn't counted by the io scheduler as process-specific. Moreover swapping seems to have the highest priority for hdd access. Maybe it doesn't even go through the io scheduler at all; it seems like the scheduler only has what's left from swapping to work with. I'm wondering why the hell that is. Seems like a very, um, silly thing for the kernel to do.
Announcement
Collapse
No announcement yet.
The Linux Desktop Responsiveness Patches Are Feeling Good
Collapse
X
-
yeah, still some jerkiness - but only in the special case of using zfs-fuse on top of a device-mapper (LUKS) device (with gzip-encryption enabled, sha256-checksumming) and scrubbing running (on around 750 GiB of data)
even 2.6.35 with CONFIG_CRYPTO_PCRYPT and tweaked /etc/zfs/zfsrc doesn't help
try to play internet-radio via amarok and you will enjoy stuttering sound at it's best (seems like this triggers some kind of problem with amarok)
since this is the only app with this issue - flash-based players, gstreamer-& mono-based banshee, etc. work fine
Comment
-
Originally posted by kernelOfTruth View Postyeah, still some jerkiness - but only in the special case of using zfs-fuse on top of a device-mapper (LUKS) device (with gzip-encryption enabled, sha256-checksumming) and scrubbing running (on around 750 GiB of data)
even 2.6.35 with CONFIG_CRYPTO_PCRYPT and tweaked /etc/zfs/zfsrc doesn't help
try to play internet-radio via amarok and you will enjoy stuttering sound at it's best (seems like this triggers some kind of problem with amarok)
since this is the only app with this issue - flash-based players, gstreamer-& mono-based banshee, etc. work fine
it was a phonon / KDE4 related problem:
switching from the gstreamer to the xine-backend "fixed" it
so nearly no stalls anymore
and I'm sure 2.6.36 will be even better (lots of improvements already got in according to the postings on lkml)
Comment
-
Originally posted by kernelOfTruth View Postforget that
it was a phonon / KDE4 related problem:
switching from the gstreamer to the xine-backend "fixed" it
so nearly no stalls anymore
and I'm sure 2.6.36 will be even better (lots of improvements already got in according to the postings on lkml)
Comment
-
Originally posted by loonyphoenix View PostI got phonon fixed by removing pulseaudio from my system. phonon-gstreamer seems to work fine with plain alsa, and phonon-xine causes some problems with Amarok. Plus, I don't think xine is being actively developed by anyone anymore...
anyways: pulseaudio is working fine now for me and I'm enjoying the additional comfort (since the kernel largely won't get into lagging anymore)
yeah, it's really a shame that xine isn't (?) developed anymore (I'm referring to the xine GUI since using it practically isn't worth it - often times it'll hardlock my box)
xine-lib (xine ?) however is still developed: http://www.xine-project.org/home
Latest news?
2010-07-25: Release
xine-lib 1.1.19
A new version of xine-lib is available. This is mainly bug fixes, but there are one or two new features, notably support for the WebM container format.
Please check the release notes for details & known problems.
Download it from our download page.
2010-03-06: Site news
#xine-vdpau
#xine-vdpau (freenode) is no more. Use #xine (alternatively, on OFTC) instead.
It has been determined that, while it was the more active channel, a lot of its content was general xine-related chat, which is more on-topic in #xine, so we've decided that VDPAU no longer needs a separate channel. If you have a problem with this, send your comments to /dev/null ☺.
2010-03-06: Release
xine-lib 1.1.18.1
A new version of xine-lib is available. This is a bug-fix release; there were a few ?minor? breakages in 1.1.18.
Please check the release notes for details & known problems.
Download it from our download page.
Comment
-
Originally posted by kernelOfTruth View Posthow would you know ?
anyways: pulseaudio is working fine now for me and I'm enjoying the additional comfort (since the kernel largely won't get into lagging anymore)
yeah, it's really a shame that xine isn't (?) developed anymore (I'm referring to the xine GUI since using it practically isn't worth it - often times it'll hardlock my box)
xine-lib (xine ?) however is still developed: http://www.xine-project.org/home
Comment
-
Originally posted by Ranguvar View PostMe as well.
if not:
patch 1&2:
[PATCH mmotm] vmscan: raise the bar to PAGEOUT_IO_SYNC stalls
fix:
vmscan: fix inconsistency reported by Kail and confirmed by Wu Fengguang
that's all you need for 2.6.35 ! (it already includes the other stuff from patch 5-7)
the 2.6.35 branch is the way to go - only the first 2 patches are needed for that because it already includes the additional ones
for 2.6.34 you need a lot more but it's also included with zen-stable
Comment
-
besides that it really DOES make a difference:
I'm currently re-testing usage of reiser4 and there are almost no stalls / hickups during webradio streaming when the filesystems needs to heavily flush things to disk (even with device-mapper & LUKS) - which definitely was a problem in the past
during heavy swapping of 1-2 GiBs (e.g. compiling chromium in ram) it's still somewhat responsive but sound is broken for several seconds-minutes (pulseaudio obviously significantly makes it worse) and the GUI also doesn't react for several (dozen) seconds
so as a summary:
the management of swapping out stuff needs some more improvements in desktop land; flushing and handling of the filesystems in general has greatly improved
Comment
-
One question folks:
I got two sets of patches. One has
Code:+ /* Check if we should synchronously wait for writeback */ + if (should_reclaim_stall(nr_taken, nr_reclaimed, priority, sc)) {
Code:+ /* Check if we should syncronously wait for writeback */ + if (should_reclaim_stall(nr_taken, nr_freed, priority, sc)) {
Comment
Comment