[kde] Re: plasma-desktop (KDE factory) acting up?
- From: Alex Schuster <wonko@xxxxxxxxxxxxx>
- Date: Sun, 31 Oct 2010 20:51:12 +0100
Alex Schuster posted on Fri, 29 Oct 2010 21:12:31 +0200 as excerpted:
Duncan, thanks for the lengthy explanation! I snipped it, as I don't
have much to comment, but I appreciate it much.
Maybe my setup is just over-complicated? When I look at screenshots
of people using KDE4, they often only have two desktops. Well, I
have eight desktops and activities, in case someone is interested,
there are some screnshots here:
The current setup is a little different, but not much.
Wow! While your customization is rather different than mine, it's
certainly as customized. OTOH, you mention below that you're a Gentoo
user too, and Gentoo's known for the customization options it offers,
so that isn't /so/ surprising, I guess. =:^)
Maybe :) I'm using Gentoo for about 8 years now. What I like most is
the continuous updating. No need to re-install a new version of my
distro every year, which has been problematic most of the times, and
still is (I maintain some Fedora and Ubuntu Servers). No installer,
which I now see as a benefit, because I fully understand what is done,
and I don't have problems with various installer bugs/problems I seem to
find. Like with my last Ubuntu install, when the Desktop version has no
LVM support. This gives great flexibility.
And yes, I like that I can customize the system and specify whether I
like my programs to be built for KDE, Gnome, or just text mode.
And I spend some time customizing my desktop, hoping that this will make
me more productive. By saving time, and more by making the work on my PC
About the many desktops, I use them for these purposes:
1 - Admin: System monitors and some shells. A folder view which I don't
use much. Xeyes, of course. Oh, I see the mouse odometer is missing. By
now I also have one xosview here (mainly because it shows paging), and
another plasmoid that shows the state of my hard drives.
2 - Multimedia: Amarok runs here, and the other window is the result of
playing with this 'window grouping' feature that came in KDE 4.4. It is
a konsole and a dolphin window combined, the window title bar acts as
tabs. The dolphin has two tabs, for music and videos, and each tab has
two views to copying data between folders is easier. The shell in the
other window is used for downloading things on the command line, or
other tasks in my /data/mpeg directory.
3 - Mail, News: Kontact and a browser with news sites I visit regularly.
Sometimes I add another browser window with twitter tabs (I don't tweet,
but there are some people whose tweets I watch), and in the screenshot
there is one more browser dealing with the soccer world championship
that was going on at that time :)
4 - Prog: I do my programming here. Some shells, a file browser, a web
browser with my company's wiki and sometimes more tabs. Two folder
views, they are the same as in desktop 1 and 4. Meanwhile I have another
one to quickly access some more stuff I often need durig programming,
like documentation and such. The calculator is not really useful.
Once I actually do someprogramming, you will find many editors and stuff
here, the screenshot shows the desktop as it is just after login.
5 - Remote: Administration of remote sites. In the screenshot I have a
KDE session via NX on a remote system, and I work with my Windows
notebook via rdesktop. The remote sites are accessed via the folder
views that open various starters for NX, FTP and SFTP dolphins, and VNC
6 - Images, and Webcomics. I also work here when using Gimp.
7 - no name: Bureocratic and financial stuff like kmymoney, online
8 - Extra/Scratch: This desktop is empty most of the time, but sometimes
I like to have a fresh desktop top start something entirely different,
play around with plasmoids, or games.
8 desktops is a lot, but don't think I could live with less than 6.
BTW: http://www.wonkology.org/comp/desktop/desktop3x3.png shows what I
had around 2004, using Enlightenment and Gnome. It's 3x3 desktops, all
combined in one 4800x3600 image. This was working quite well, with 1G of
RAM. I had a Windows XP running in VMware most of the time, over 20
shells, with 20 of them saved in the session so the opening every time I
logged in. And as I see in the screenshot, I was using 750M of swap
space, 3/4 of my total memory. This desktop felt much better than my
current one does. This is crazy!
FWIW, it's rather old (4.2 era, when I was switching from kde3 to kde4
and still had elements of both installed and running, together), but I
still use a generally similar arrangement to the one in the screen
I still have dual monitors in stacked config, tho I'm now running
slightly shorter ones, standard US 1080p HD, so the overall resolution
Cool, now this is huge! Um, are these monitors _physically_ on top of
each other, or side by side?
Likely as a result of the additional screen space the dual monitors
gives me, I don't actually use as many desktops as I might.
I might somehow live with only four then.
use three, and only have a single "activity"... tho due to the way
plasma worked pre-4.5 each monitor formerly displayed a different
"activity", but the two formed a single desktop. 4.5 has changed that
somewhat and it's clear that the intent is to have the whole desktop
be the activity, even if each monitor has its own separately
configured background, but again, it's clearly a WIP (work in
progress), which sort of works, but I expect will be MUCH more
polished and functional in 4.6 (what arguably should have been kde4's
.1 release, by traditional measures).
I still have the big panel at the top, now all plasma, of course, with
the system activity graphs that were provided in the screenshot by
kicker's ksysguard applet now provided by the yasp-scripted
(yasp=yet-another- systemmonitor-plasmoid) plasmoid off of
kdelook.org, since there appears to be no proper ksysguard plasmoid to
replace kde3's kicker applet. In addition to the several
yasp-scripted sysmon plasmoid instances (including one tailing
syslog), this panel also includes the systray.
Does the one tailing syslog work like tail --follow=name? That is, when
the file gets renamed due to log rotation, does it show the new file? My
plasmoid shows metalog's /var/log/everything/current, but once per day
this file gets renamed and an empty one is created, which the plasmoid
does not show then.
Oh, wait - I googled the yasp plasmoid, downloaded it, and found a tail
-f command in the yasp_scripts/systemmonitor.script file. So that would
be easy to change. Oh, there's a directory named duncan-yasp-scripts :)
Window-placement-wise, I REALLY like the drag-to-side-half-maximize (to
monitor, so it stays in the active monitor not over both) feature that
appeared in 4.4 and use it a LOT! (OTOH, on a dual-monitor stacked
config, the drag-to-top-to-maximize functionality is annoying, since
it triggers when dragging to the top of the BOTTOM screen too, and
that's the MIDDLE of the desktop. So that option's turned off.) My
normal config (with kiwn's customized window-rules applied to help)
runs both konsole and konqueror (my default browser, tho I use firefox
as well) half-maximized, so I get two instances side-by-side.
I don't use this feature that often, but I like it, it is very
convenient sometimes. One of the many things I would miss when going
away from KDE.
Even cooler is the feature I mentioned that allows to group windows
Kmail, akregator and pan (USENET/news client, about the only gtk app I
run other than firefox) run almost-maximized in the bottom monitor,
with pan getting its own dedicated "news" desktop. (As I mentioned
above, I only run three desktops, pan on one, and two others so I can
have whatever project open on one and still have the other for a
second project or as a free/overflow desktop.)
I say "almost-maximized", because I use custom kwin window rules to
keep those apps a title-bar's height shorter than full maximized.
That way, I can run a half-maxed browser/konsole/whatever on the same
bottom monitor and still conveniently click-raise either the
almost-maximized app or the other one, without trouble (focus follows
mouse policy, click-to-raise, additionally, window transparency allows
me to focus the "underneath" app and work in it "thru" the on-top app,
when necessary -- this is why I find transparency almost indispensable
I installed KDE 3.5 just to compare, and it seems to be much faster.
But I got used to KDE 4, and would not want to switch back. Maybe I
will, if things will not become better soon. First I will add
another 2G of memory, and let's see if 8G will be enough then to
make KDE4 run fast.
It's interesting that your experience is so different than mine, when
we're both running KDE 4.5.2 on Gentoo.
Now while my system is somewhat old now (2004 era), it was well beyond
the desktop system of the time, with dual socket Opteron (originally
single- core 1.6 GHz Opteron 242s, now dual-core 2.8 GHz Operon 290s,
the top of the line as far as socket 940 goes). If you're only
running a single single-core, that's no doubt part of it, but it
doesn't explain the memory issues you mention.
Here: AMD Athlon 4850e dual core @ 2.5 GHz.
Originally, I had 8 gig (4 sticks @ 2 gig each) RAM, but one stick died
and I've not replaced it, so I'm at 6 gig now. But even with all the
stuff I run, I wouldn't expect to have a problem even if I lost a
second stick bringing it down to four gig, and in fact I'm on record
as saying if I had it to do over, I'd get 4 1-gig sticks instead (the
four sticks allows more efficient multi-channel memory access), since
I'm seldom using more than 4 gig, INCLUDING CACHE. While I do put the
extra memory to work when I'm doing upgrades (using portage's parallel
MAKEOPTS="-j13 -l10" and defaulting to emerge --jobs=4
--load-average=7, with PORTAGE_TMPDIR in a 5 gig tmpfs), even that
seldom pushes memory above 6 gigs usage into swap (it'll typically go
a a few MB in, 10-20) -- and that's even with kernel swappiness=100,
so it's going to swap instead of dumping cache.
Wow, that's a difference. I have swappiness=20 already. I will try
compcache (compressed swap space in RAM, just read about that), let's
see what this gives.
But there's three differences that I'd guess make up a majority of the
1) With a few noted exceptions, my general work pattern closes apps
when not in use.
Not here. I got used to not closing applications, just in case I might
need them later. This used to work very well, and I think it should. An
application that is not being used should get swapped out when memory is
needed, and as long as there is enough swap, there should be no problem.
But even when I close additional stuff that is not in the saved session,
this does not seem to help much. I think, I will have to explore this
While I may run days to weeks without a reboot (and
then it's usually to test a new kernel, I run direct linus mainline
git and do regular pre-release kernel testing and bug reporting, among
other things), and may run kde for days between kde restarts,
typically, I don't keep /that/ many apps running. In particular,
firefox is said to be a big memory hog if left running for days at a
time with a lot of tabs, and my default browser is konqueror and I
don't often open more than a handful of tabs or keep them open for
more than a few hours, max, so while I use firefox some, I just don't
have the issues with it that many report, as I just don't use it that
way. Even with konqueror, tho, I tend to open a window, only open
links in that window as new tabs, and only keep the window open a few
hours, tho I often have three or more independent konqueror instances
running at once.
Oh, I have many more. Currently, chromium uses 1125 MB. I wrote a little
shell script that totals the RSS column in the ps aux output.
I also don't run servantware (in the context of the sig) apps, so no
flash or the like to bug out on me. =:^)
I don't like flash, but I don't want to miss it either, so I have it
activated :-/ nspluginviewer often takes lots of CPU, so I kill it
regularly. The red circles with the white X inside on my desktop are for
this. I press this about a dozen times a day.
It's worth noting that while your reported plasma-desktop memory usage,
resident, according to top, reaches a gig, here, top does report it as
the biggest resident memory user, but only by fractions of a MB, with
both it and pan (ranked second) reported by top to have 93 MB
FWIW, here's some other plasma mem numbers according to top:
VIRT 930 MB (virtual memory is the amount the app has asked the kernel
to allocate, but traditionally, most apps use very little of it, such
that the kernel over-commits by a rather big ratio, 50:1, by default,
SWAP 838 MB (swappable, not necessarily swapped, as it isn't here since
I'm running 0 MB swap ATM).
SHR 36 MB (shared, this memory is potentially shared between a number
of apps using the same libs).
93 MB resident here vs a gig there? Something tells me you've a
problem, and one of the differences is your 8 desktops with an
activity per desktop, vs my three desktops, same activity (or set of
two activities back on kde 4.4, one per monitor) on each.
Sorry, I see I forgot to write something about that. I was composing a
similar text in a forum, and got confused.
pasma-desktop started using > 1G of memory aftert the last upgrade from
4.5.1 to 4.5.2. When I logged into KDE after the upgrade, the usual
KDE-is-starting animations appeared, but when it disappeared, I got a
black background, and thought something went seriously well. But after
some minutes, all plasma stuff appeared.
When I watch the process with top while starting (or restarting after a
crash), I see memory climbing, until it is at 1.3G, and then I have my
plasma desktop back.
So, this problem is new, but before, with KDE 4.5.1, I also experienced
swapping already, and things were slow. Maybe not _that_ slow as they
Also possibly of note while still on #1, you mention running chromium,
which (like firefox but worse) bundles its own copies of many system
libraries, so memory that's normally shared between apps using the same
library is exclusive to chromium, with its bundled library copy. As I
said, firefox does some of the same thing, but at least on Gentoo,
they've force-unbundled more of the libraries with firefox than with
chromium, so it uses more of the shared system libs. Another factor
would be the separate VMs chromium uses for each tab, much stabler and
more secure, but not exactly memory miserly. If you're running the 50
tabs for days on end that I've seen some folks talking about running
on firefox, that /might/ be part of it.
Hm. I switched to chromium for the reason, that konqueror had a serious
bug 3-4 months ago. About once per day, I suddenly could not move the
focus away from konqueror. Or, more specific, from the last widget/area
inside konqueror that I used. So I could do things in the current tab,
but not switch them, or access the menu bar. I could switch applications
by keyboard shortcut, but then this application was only partially
functional. Took me a while until I found out this is linked to
konqueror. Finally, I dumped it, and tried chromium, after someone on
gentoo-user suggested it as being fast. And it was, and actually it used
less memory than konqueror! Flash worked fine (it also does in
konqueror, but at that time it didn't), and I did not have a single
chromium crash since then.
I'm thinking about going back to konqueror, which I still like more. But
what I like about chromium is that it saves all open tabs when logging
out, and when I restart it, all is as it was before. Konqueror does
something similar in KDE4, when I log into KDE I am asked whether I want
to restore the last session. But it does not work that well, and it
would open konquerors additionally to the ones saved in my session. And
all are the same process then, if one dies, all windows die, while the
konquerors that are opened by restoring the session are different processes.
I could save the session whenever I log out, but I like the session to
be tidy when I start, without all the other stuff I had running when I
logged out. And as I wrote, saving the session often does not work, and
everything will open on the first desktop.
But so far, we definitely know something's up with your plasma, as a
gig of resident really does seem abnormal. Why? Well, see #2 and #3.
2) I'm running gcc 4.5.1 here, with --as-needed in my LDFLAGS (it's
there on Gentoo by default now, but that's a rather new change so if
you've not done a full emerge --emptytree @world in awhile...).
I'm using gcc 4.4.5 and have --as-needed in LDFLAGS, but while I do
@world updates quite often, I never used --emptytree on this system. I
Installed it in June when I went from i686 to amd64, using gcc 4.4.4.
Oh, and the system felt quit fast then! Much more responsive than it was
before, with identical /home. I even removed 2G so I had less memory
than the 3.3G I had on the i686 system, and it still was faster. So the
speedup was not only because I could use the full 4G now. No idea what
that was. And no idea why it became slow again soon. I did not notice
this first, it seems like it did not change all of a sudden, but
gradually. Like if some heavy, heavy file system fragmentation happened.
Which does not seem to be the case.
When I'm not using the system heavily, it's fine, but when I work
heavily with it, it will eventually start swapping.
I will investigate this further and log memory consumption.
Newer gccs might be a bit more efficient in that regard, and having the
whole system built with the same compiler is likely to make system
library memory sharing work better, I'd guess, as well. The
--as-needed in LDFLAGS might be a bigger factor, however, as otherwise
the linker will link in libraries that really aren't needed, and if
those are then loaded at runtime... Note that I also have -z,now in
my LDFLAGS. That causes the loader to resolve all symbols at app init
time, which will pull in more code then, but it then won't have to be
pulled in later. Normally that'd cause apps to use MORE memory, not
less, but it's possible the effect of forcing initial symbol
resolution allows more efficient library sharing, reversing the effect
system-wide, I'm not sure. But the effect will in any case be less
with --as-needed as well, since less actually unneeded code will be
linked and therefore force-loaded by the on-init loading.
It's also somewhat possible that an earlier version of gcc had a bug
that I didn't run into with gcc 4.5.1. Again, it's possible that
having parts of the system compiled with different compilers could
magnify the issue. It's not for nothing that Gentoo's gcc upgrade
guide recommends doing an emerge --emptytree @world after a gcc
upgrade, tho I normally only do it after feature version bumps (4.4 to
4.5, not the bugfix 4.5.0 to 4.5.1 that I recently did, but I did an
--emptytree recently for other reasons).
This has been discussed several times on the gentoo-user mailing list,
and the general consensus there is that recompilation of the whole
system is not necessary normally, only when the ABI changes, which
happened the last time when gcc went from 3.3 to 3.4.
But hey, why not, my system is running all the time anyway, so even if
it slows thinsg down, I can let it compile while I am sleeping. I heard
sone good things about th enew gcc, but thought I'd wait until it is
considered stable. But when your experiences are good, I'll give it a
try. So, I would add the graphite USE flag, and add -floop-interchange
-floop-strip-mine -floop-block to my CFLAGS? I just read that (again) in
a thread on gentoo-amd64, you were involved there, too :) Not sure if I
also should add the lto USE flag and add -flto to CFLAGS as also
sugestend in the thread.
3) I know from personal experience that graphics hardware and drivers
make a **HUGE** difference in how well kde4 runs. "Drivers" includes
not only the xorg driver, but the kernel dri/drm module as well, plus
mesa, libdrm, and xorg. I tend to run ahead of ~arch, as I'm running
the xorg overlay, and I already mentioned I run mainline linus git
kernels. Also, I don't do servantware, so no nvidia/frglx here!
My graphics card is a Radeon hd4650 (r7xx series, my old one was an old
Radeon 9200, r2xx series, thus the personal experience of the
difference it makes!), and here's the graphics stack I'm running:
kernel (linus mainline) 2.6.36 (actually still a few git commits back
from that, 2.6.36-rc8 plus a few commits, I've not upgraded since the
ATI Radeon HD 3200
I had tried newer X servers, but than I had X crash after a minute. And
I'm not satisfied with the radeon drivers either, I get lots of graphics
distortion when scrolling in applications. This gets better when I turn
desktop effects off, which is bad because I like them. Maybe I should
try the fglrx closed-source driver again, but I had much problems with
that (but this were older versions), there seemed to be a memory leak,
and all the swapping was even worse than now.
I'm using tuxonice-sources-2.6.34-36. Oh, Tux On Ice. Another of these
things I put some time into, and that just don't work well. But this is
the wrong list for this.
Again, those are recently recompiled along with the entire system using
kde 4.5 does have known issues with certain graphics cards and drivers,
including radeons, but it's said to be better if you're running the
latest, which I am. If you're running something older, or if you're
running servantware drivers, or if it's not all compiled with the same
gcc/ binutils, that could be part of it. Actually, I'd not be
surprised at all to find this was the biggest issue, right here, given
the known issues in the area, and the abnormal gig resident for
plasma-desktop you're reporting.
I'm seeing the comic-strip-plasmoid related crashes here as well.
Only the plasmoid, or the plasma-desktop process?
After chasing down a different (non-kde) graphics bug I was seeing, I
have a suspicion that I've not had time to verify.
What version of cairo are you running? Here:
Apparently cairo 1.10 "changed ownership semantics" in some way vs.
previous versions. That's in quotes because it's very close to the
words used by the dev that traced down the non-kde bug I mentioned,
and I don't know enough about cairo to have a clue. But I do know
that when he adapted his code to work with the new semantics, it did
away with the problem.
Now, if I'm not mistaken, cairo originated as a gtk/gnome vector
graphics rendering library, but it's used more widely now, including,
it would seem according to equery depends, qt-gui and thus kde.
What I suspect but haven't yet verified is whether masking
~cairo-1.10.0, thus forcing a downgrade to cairo-1.8.10, suddenly
resolves this bad comic- strip-plasmoid crashing issue!
Perhaps you could try it and see?
I did so and logged out and in into KDE. I tried all the comics,
including the 'Perls Before Swine' compic that never showed something
(BTW, could you try if this one works for you?), looked good. But then,
it finally crashed after some more playing with it. That is,
plasma-desktop crashed, not only this plasmoid.
BTW2, another annoying thing is that it doe snot keeps the size I give
it, and gets really small when I change the comic. I always view them
with the middle mouse button.
I also found this file when analyzing why my activities were on the
wrong desktops. I was able to fix this manually for some times by
exchanging some of the numbers. When it happened again, I simply
restored a backup copy of this file.
Oh, speaking of backups: I make lots of them. I never save the
session without making one of my ~/.kde4 directory, because it often
does not work and all applications open on the first desktop, for
example. Or the plasmoids are all mixed up again.
Ugh! FWIW, activity application tracking should be much improved with
4.6, I've seen that blogged already, even tho I'm not following it as
closely as I once did.
The mixed-up plasmoids... probably part of the same bug this whole
thread is about, and hopefully fixed with 4.6 if not before. But I
don't know that for sure via blog of the dev.
BTW, what I am missing is a possibility to move plasmoids around to
other desktops/activities. Or is there already another method than
deleting and re-creating a plasmoid? I'd also like the option to make
them sticky on all activities, similar to windows being visible on
all desktops. Even better would be the possibility to select
multiple desktops/activities for plasmoids and windows.
Moving the plasmoids between activities... used to be possible using
the zooming interface, I think, but I don't know how to do it using
the new interface. Of course it should be possible by directly
editing that file mentioned above, changing the numbers appropriately,
but that's definitely "advanced users only" territory, given the
hassle involved ans risk of totally screwing the entire plasma config
if one isn't careful.
Yeah. And I always fear that I make a slight mistake that might trigger
all sorts of weird side effects, and I will never know.
The other stuff... there's STRONG hints in the blogs that this general
type of thing is already what they're planning, and I definitely expect
to see at least some of it for 4.6. But I doubt we'll see anything
like their full vision for activities before 4.8 or so (by which time
they'll have even more ideas, of course)... another full year plus,
from now. What the specific increments for 4.6, 4.7 and 4.8 might be,
however, I couldn't guess at this point.
Oh dear. Hey, I'm already waiting for a year now for KDE to become stable :)
Oh, and plasma-desktop just crashed again, when I gave the comic
plasmoid anopther try. After 4 1/2 minutes, des desktop is back, and
plasma-desktop takes 1.3G of memory. And I suddenly have a minimized
'JavaEmbeddedFrame' in my panel which I cannot maximize. It
disappeared after a while.
Well, time to log out and in again, as I do every 1-2 days in order
to make KDE4 fast again, at least for a while until the swapping
Hopefully something in the above is helpful, as a gig of resident for
Well, many many thanks for your large mail and the ideas! At least it
will give me an improved syslog monitor :)
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
More info: http://www.kde.org/faq.html.
- Prev by Date: [kde] How to approve Linux distributions into Distrowatch?
- Previous by thread: [kde] Re: plasma-desktop (KDE factory) acting up?
- Next by thread: [kde] Re: plasma-desktop (KDE factory) acting up?