Duncan wrote: > Dale posted on Wed, 22 Feb 2012 21:47:18 -0600 as excerpted: > >> I am mostly curious right now. I used to use Konqueror as my file >> manager. I noticed when I left it idle for a bit, it would start using >> 100% of one of my cores. It has been doing this for a while so I can't >> say which upgrade it started on. Anyway, when it started doing this, I >> switched to Dolphin for my manager. I thought maybe it would be more up >> to date or something. Anyway, it does the same thing. >> >> When I use top, or htop, to show what is using so much CPU, it is >> kdeinit4 at the beginning but either Konqueror or Dolphin as the actual >> process running. I'm not sure what triggers this issue right now. I >> usually use it to watch videos or something. It doesn't do it in a way >> that is reproducible yet but I am trying to figure out what triggers it. >> When I close the file manager, the CPUs go back to normal. >> >> I'm using Platform Version 4.8.0 but it was doing it on the last version >> too. >> >> Has anyone else seen this? If so, any fix yet? > > I'm not sure if this is what you're seeing, but see if it fits... > > If previews are enabled in konqueror/dolphin, and you're in a directory > with a large number of images or even more so videos, they will use a lot > of CPU trying to generate thumbnails for all those image-files. Videos > take more cpu and will I believe only be thumbnailed if you have the > appropriate thumbnailers installed (mplayerthumbs and/or another similar > app the name of which IDR ATM). > > Once all the thumbnails are generated, there will be a burst of cpu on > directory entry as it checks the hashes and loads the corresponding > thumbnails, but it will die down MUCH sooner. But until they're all > generated, there will be a pause to let the pre-generated thumbs load, > then if there's no activity, the background thumbnailing process will > startup again. If it doesn't finish before you close the window or go to > a different dir, it will start up again the next time where it left off, > so in a few-hundred-video-dir, it might get maybe 3-5 videos each time > during normal usage if you're in the dir only a little bit, and thus take > maybe a hundred visits to the dir before all the videos are thumbnailed. > > As such, the pattern is much different before all the videos are indexed > (initial burst, wait, pick up again) compared to after (longer initial > burst as there's more thumbs to load, without the pickup again). > > A possible snag in this is if the various components (mplayer, the > thumbnailer, dolphin/konqueror, various kde and other libs) get out of > sync with each other. That could stop the activity until they're back in > sync, or make it much worse as the thumbnailers repeatedly try to load, > and crash, without actually generating any new thumbnails.
I been messing with this for a bit. I just plain old disabled the preview stuff for everything including the desktop icons. The desktop setting was easy but I can't get dolphin to retain the settings after a restart. If I close then restart dolphin, everything resets to defaults and plain ignores my settings. So, one problem has uncovered another. How do I FORCE dolphin to retain my settings? Do I need a bolt, nut and a good set of wrenches? I got some. Grade 8 bolts and Craftsman 1/2 inch drive sockets. I also have a 6 foot cheater pipe and a pull handle too. I need this thing to tighten up a bit here. lol > > As both you and I are gentooers, a revdep-rebuild can help here, but I'm > not sure it catches /all/ such issues. (It catches most library out-of- > syncs, but I'm not sure it catches plugins, which often only load on > specific actions and won't normally cause problems if they're not there, > like fully depended libs will. And there's multiple ways to load a > library and I'm not sure revdep-rebuild catches all the obscure ones.) I > do know that revdep-rebuild sometimes reports all clean, here, but still, > something doesn't work for a time, but then when all the updates happen > to be built in the correct order again, suddenly things work again. > There's two cases I've seen where this seems to happen, the thumbnailers, > and the gnash/lightspark flash replacement plugins. I simply don't have > the technical understanding to really grasp /why/, tho I believe I sort > of understand a bit of it (the different ways to load libs, and the case > of libs vs plugins, both of which are "shared objects", aka *.so.*). > My usual upgrade path is, eix-sync && emerge -uvaDN world then --depclean then revdep-rebuild -i. I tend to keep my system saner than me. o_O > > The kdeinit4 thing is a trick kde uses to launch faster and be a bit more > efficient with resource usage. Instead of each kde infrastructure app > loading all its resources separately, kdeinit4 is used to load common > resources once for several apps, thus shortening the initial launch and > reducing memory usage. The following is rather simplified, but AFAIK, > it's reasonably accurate as the high level explanation it's intended to > be: > > In Linux as originally designed, "shared object" libraries can load once > and be shared by as many apps as need them, but that was back when > libraries loaded at predictable locations. Now days, various archs > (including amd64/x86_64) mandate and some distros use even on x86, > "randomized memory space object relocation", for security and other > reasons. (Security-wise, if a function's location can be predicted, it's > far easier to exploit a potential vulnerability to allow an attacker to > take over the machine.) Also, even when shared object libs try to load > at specific locations, they can only do so if other libs aren't already > at that location, in which case they must be loaded elsewhere anyway. > > Unfortunately, libraries loaded at different locations in different apps > take longer to initialize and don't as effectively share memory. Thus, > kdeinit4, which allows the various kde4 "core" apps to all load together, > more effectively sharing resources and loading faster. Address space is > still randomized at load time for these apps so security isn't thrown out > the window, but it's randomized once for all of them together instead of > once for each one. > > If one of the apps crashes, it can be rerun by itself, but of course the > benefits of the common init are lost that way. Since it's just one app > being reloaded, init time isn't as big an issue, but other things being > equal, memory usage will be slightly higher. And AFAIK, kdeinit4 can't > be used to just rerun the single app anyway. If a full rerun is desired, > you quit kde back to the *DM login or text console (depending on how you > launched it in the first place, I always use a text console launch and > never a *DM graphical login, but others prefer their graphical login), > and relaunch. > > That should address the kdeinit4 <app> angle. =:^) > > > Finally, FWIW, for file browsing, in kde4, konqueror loads the dolphin > kpart. The wrapper around the kpart is different between dolphin and > konqueror, but it's the same dolphin file browser kpart underneath. So > it's not surprising that behavior and bugs seen in one are often seen in > the other, as well. It simply depends on whether that aspect is part of > the wrapper UI, or an underlying behavior of the kpart. > > Is KDE taking after winders? ROFL I noticed the other day that it now shows dolphin on the front. Maybe it was the way I was running the command. < shrugs > >> Also, I had to disable previews on my Desktop. When I would hover the >> mouse over a icon, it would kill the kicker at the bottom and my >> wallpaper. It would kill processes to the point that I could not logout >> normally. I could not right click on the desktop and since the kicker >> was gone, no K menu either. I'm not sure if these could be related and >> most likely are not but it is a odd thing. On this matter, I have mine >> set to show the icons on my desktop. I think it is called "folder >> view." > > FWIW, "kicker" was the kde3 panel app (kdesktop was separate). In kde4, > the entire desktop and panels are "plasma" (plasma-desktop normally, > plasma-netbook's used in some cases). KDE /does/ try to respawn plasma > if it crashes, but it doesn't always catch it, and of course if the > problem is bad enough it could crash repeatedly. > > However, while in kde4 the desktop and panels are combined, krunner is > deliberately kept as a separate process even tho it uses many of the same > libs, precisely to keep either krunner OR plasma-desktop usable if the > other one crashes. > > Thus, even with plasma crashed, you /should/ be able to still use the > krunner hotkey (alt-F2 by default, IIRC) to invoke it, and can type in > whatever you'd launch that way, including rerunning plasma-desktop from > krunner. > > If you have a konsole window open, you can of course run either one > (plasma-desktop, krunner) from there as well. And of course you can run > konsole from either plasma or krunner. > > Similarly, the hotkey mechanism appears to be separate. (I've not > actually figured out what app is responsible for it as I no longer see > the khotkeys app running that kde3 had, but I've had both krunner and > plasma crash on me at various times, and the hotkeys still appear to > respond with either one down, so it's gotta be separate from either.) > Thus, it's possible to configure hotkey launchers for plasma-desktop, > krunner, kwin, and konsole, so you can always get them back as long as > the hotkeys component is still running, with just a press of the > appropriate hotkey combination. > > > FWIW (tl;dr: description of my setup follows)... > > Here, to replace the missing multikey hotkey functionality in kde4 that > used to work so well in kde3 (FWIW, the relevant kde bug says it's due to > a qt4 defect, apparently unfixable in qt4 as it's an architecture > assumption, but I've read that it's already fixed in qt5), I've setup a > couple scripts and a whole set of launcher-config files, that allow a > three-key launch of pretty much anything I use regularly, including > launchers for the apps listed above, should they crash. The first key is > a khotkey that invokes my launcher with a list of categories (config=c, > filesystem=f, games=g, net=n, raid=r, terms=t, X=x, etc) and associated > hotkey, the second choses a category and invokes the launcher again with > a list of the apps/hotkeys for that category (for net, b=bank (browser > loading the bank's login page), z=bugZilla-gentoo (browser URL), F=firefox > (general launch, blank page), m=mail (claws-mail, mail instance), f=feeds > (claws-mail, feeds instance), n=news (pan, nntp news client), etc). > > So if I want to launch a konsole window, it's simply <launcher-key>,t,t > (first t, terminals category, second, general terminal window), to launch > konsole directly sudoing to my admin user, it's <launcher>,t,z, to > relaunch kwin with the --replace parameter if it crashes, it's > <launcher>,x,w (x=X-category, w=kWin), to launch kpat it's <launcher>,g,p > (games, kPat), getting a browser open to the bank login page is > <launcher>,n,b (net, bank), to open kde settings s <launcher>,c,s > (config, kdeSettings), to relaunch a crashed krunner it's <launcher>,c,r > (config, kRunner), to activate and mount my media raid it's <launcher>r,m > (raid, media)... etc. > > Just three keys to launch anything on the system I use enough to have > bothered setting up an entry for it in the launcher config! =:^) And > it's all nicely categorized and mnemonically arranged so I normally > remember it without prompts, but the category and individual apps lists > for that category popup, just in case. =:^) > > And as can be seen from the examples, that includes restart launchers for > kwin, krunner, plasma-desktop, etc, along with such things as config > resets for mouse accel (sometimes that resets and the mouse moves like > molasses until I reset the accel), triggers to immediately turn off the > monitors, or conversely, to keep them on so they don't blank on their own > after X minutes of inactivity, triggers to run a script to assemble > various auxiliary md/raids and mount the filesystems they contain, > triggers to load the browser with specific pages... all the random misc > one-shot and app launcher stuff I might want to do on the system. > > Of course, if there's an app I'm not familiar with or simply don't use > enough to have created a 3-key launcher, I can use the usual launch > methods, kickoff menu, typing it in krunner, launching konsole and using > tab-complete to launch it from there, etc, that an ordinary user might > use, as well. > I use the same stuff over and over so I just save the session and it opens everything when I login. It even launches Seamonkey now. It didn't use to do that. It seemed to launch everything KDE related but not apps outside of KDE stuff. Glad that is fixed. I did just notice something. In dolphin, there is a PREVIEW button right there in my face. It's right below the menu button thingy. I clicked on it. Maybe that will help. Of course, I have to remember to click it every time I open dolphin tho since it won't save my settings. This is a lot easier for me on Konqueror. It generally "just works" for me. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n" ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
