| Summary: | Odd disk activity during file copy operations if progress panel is shown | ||
|---|---|---|---|
| Product: | [Unmaintained] plasma4 | Reporter: | Janne Pikkarainen <jaba> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | aseigo, jaba, kay.abendroth, maxliscia, null, peter.penz19, progger1986 |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Janne Pikkarainen
2009-02-26 20:35:36 UTC
Thanks for the report, I've forwarded this issue to the plasma team and stay on CC. @plasma team: Please let me know if you think this is not in your responsibility. Thanks for the extremely fast response! It seems I can't upload attachments to this 'zilla, so here's the video clip I mentioned in my bug report: http://jaba.mbnet.fi/odd-disk-activity-dolphin-while-copying-files I also straced the process with "strace -p `pidof plasma`". What in the world plasma is doing with some theme index + lock files?
---
open("/var/tmp/kdecache-jaba/kpc/plasma_theme_Oxyglass.lock.aM5642", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 18
fchmod(18, 0644) = 0
uname({sys="Linux", node="lappy", ...}) = 0
write(18, "5642\n"..., 5) = 5
write(18, "plasma\n"..., 7) = 7
write(18, "lappy\n"..., 26) = 26
link("/var/tmp/kdecache-jaba/kpc/plasma_theme_Oxyglass.lock.aM5642", "/var/tmp/kdecache-jaba/kpc/plasma_theme_Oxyglass.lock") = 0
lstat64("/var/tmp/kdecache-jaba/kpc/plasma_theme_Oxyglass.lock.aM5642", {st_mode=S_IFREG|0644, st_size=38, ...}) = 0
lstat64("/var/tmp/kdecache-jaba/kpc/plasma_theme_Oxyglass.lock", {st_mode=S_IFREG|0644, st_size=38, ...}) = 0
_llseek(18, 0, [0], SEEK_SET) = 0
close(18) = 0
unlink("/var/tmp/kdecache-jaba/kpc/plasma_theme_Oxyglass.lock.aM5642") = 0
stat64("/var/tmp/kdecache-jaba/kpc/plasma_theme_Oxyglass.index", {st_mode=S_IFREG|0644, st_size=33656832, ...}) = 0
stat64("/var/tmp/kdecache-jaba/kpc/plasma_theme_Oxyglass.index", {st_mode=S_IFREG|0644, st_size=33656832, ...}) = 0
stat64("/var/tmp/kdecache-jaba/kpc/plasma_theme_Oxyglass.index", {st_mode=S_IFREG|0644, st_size=33656832, ...}) = 0
stat64("/var/tmp/kdecache-jaba/kpc/plasma_theme_Oxyglass.index", {st_mode=S_IFREG|0644, st_size=33656832, ...}) = 0
stat64("/var/tmp/kdecache-jaba/kpc/plasma_theme_Oxyglass.index", {st_mode=S_IFREG|0644, st_size=33656832, ...}) = 0
unlink("/var/tmp/kdecache-jaba/kpc/plasma_theme_Oxyglass.lock") = 0
clock_gettime(CLOCK_MONOTONIC, {10302, 746697381}) = 0
clock_gettime(CLOCK_MONOTONIC, {10302, 746730067}) = 0
lstat64("/var/tmp/kdecache-jaba/kpc/plasma_theme_Oxyglass.lock", 0xbfb85e18) = -1 ENOENT (No such file or directory)
stat64("/tmp/kde-jaba/", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
stat64("/var/tmp/kdecache-jaba/kpc", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
open("/var/tmp/kdecache-jaba/kpc/plasma_theme_Oxyglass.lock.TA5642", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 18
fchmod(18, 0644) = 0
uname({sys="Linux", node="lappy", ...}) = 0
write(18, "5642\n"..., 5) = 5
write(18, "plasma\n"..., 7) = 7
write(18, "lappy\n"..., 26) = 26
link("/var/tmp/kdecache-jaba/kpc/plasma_theme_Oxyglass.lock.TA5642", "/var/tmp/kdecache-jaba/kpc/plasma_theme_Oxyglass.lock") = 0
lstat64("/var/tmp/kdecache-jaba/kpc/plasma_theme_Oxyglass.lock.TA5642", {st_mode=S_IFREG|0644, st_size=38, ...}) = 0
lstat64("/var/tmp/kdecache-jaba/kpc/plasma_theme_Oxyglass.lock", {st_mode=S_IFREG|0644, st_size=38, ...}) = 0
_llseek(18, 0, [0], SEEK_SET) = 0
close(18) = 0
Just a wild guess (I've never actually read KDE 4.x source code): maybe plasma is creating a new lock file and then removing it every time the progress bar needs to be updated? That can't be right. A temporary work-around (for me) would be to move my /var/tmp/kdecache-jaba to /dev/shm, but that would not be right, either. :-) I took a quick peek to KDE's code via websvn.kde.org. For me it seems that KDE attempts to cache theme related pixmaps, but for some reason in this case it fails to do so, discarding the whole cache for that plasma info popup, and thus creating the disk activity. Was that right? :-) So my guess is that ThemePrivate::discardCache() gets called from some unexpected place. http://websvn.kde.org/trunk/KDE/kdelibs/plasma/theme.cpp?view=markup Oh well. Gotta go to sleep, I'll try to investigate this further to help you more. *** Bug 183557 has been marked as a duplicate of this bug. *** *** Bug 185883 has been marked as a duplicate of this bug. *** Out of curiosity, I just copied my /var/tmp/kdecache-jaba to /dev/shm/kdecache-jaba, symlinked /var/tmp/kdecachejaba to /dev/shm/kdecache-jaba and logged in to KDE. Or in Unix-speak: --- mkdir /dev/shm/kdecache-jaba cp -pr /var/tmp/kdecache-jaba/* /dev/shm/kdecache-jaba chown -R jaba /dev/shm/kdecache-jaba mv /var/tmp/kdecache-jaba /var/tmp/kdecache-jaba.bak ln -s /var/tmp/kdecache-jaba /dev/shm/kdecache-jaba --- Overall feeling is a bit snappier, for example clicking on taskbar clock (to open the calendar) doesn't cause any disk activity and calendar pops up instantly. yes, according to those straces it's evident that an svg is being repeatedly cached and destroyed. my guess is that it's the progress bar... it's painting using an svg which is automatically caching behind the scenes .... only it's changing it's size quite often which results in re-caching over and over. in the case of something moving like the progress meter, it's really counter productive to do caching at all. i'll whip up a patch to allow svg's to bypass caching under such circumstances. SVN commit 967637 by aseigo: turn off caching when we are rending the bar BUG:185642 M +7 -1 meter.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=967637 |