Gentoo Archives: gentoo-user

From: Dale <rdalek1967@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] KDE plasmashell and wallpapers.
Date: Tue, 24 Dec 2019 23:27:24
In Reply to: Re: [gentoo-user] KDE plasmashell and wallpapers. by Wols Lists
1 Wols Lists wrote:
2 > On 24/12/19 22:23, Dale wrote:
3 >> Wols Lists wrote:
4 >>> On 24/12/19 20:33, Dale wrote:
5 >>>> I think it is indexing/caching/something that requires it to look at
6 >>>> every single file in there plus all the levels below it. If so, that
7 >>>> would be a huge task. Here is some info on that but I did post it a bit
8 >>>> ago. It was sort of nested in one of the posts.
9 >>> Exactly. The thing about what this developer noticed is that it is the
10 >>> READING THE FILES that kills the system performance. The indexing is
11 >>> just random noise.
12 >>>
13 >>> So once this fix gets into the system it won't matter that it's indexing
14 >>> - the indexing will stall waiting for the files to be read, and reading
15 >>> the files won't kill the system.
16 >>>
17 >>> What seems to be happening at the moment is that as plasma reads the
18 >>> files, linux is paging plasma out to make way for the files, then it has
19 >>> to drop old cache to page plasma back in, and it's just got stuck in
20 >>> treacle trying to "in out in out shake it all about" :-)
21 >>>
22 >>> Cheers,
23 >>> Wol
24 >>>
25 >>>
26 >> I suspect the dev that did this, has very few wallpapers or doesn't use
27 >> the feature at all and just has one pic he changes manually from time to
28 >> time. lol
29 > Apologies, but did you bother to read what I wrote? The fault has
30 > ABSOLUTELY NOTHING to do with Plasma or KDE.
31 >
32 > I'm inclined to agree that KDE should try and work round bugs, but the
33 > real fault lies in the Linux kernel.
34 >
35 > I'm a kernel dev wannabe, and following what's going on can be VERY
36 > enlightening - this is a design fault, and I'm sure there are plenty
37 > more ... :-) it can be VERY frustrating as an app developer to find that
38 > what *should* be nice and simple is made horribly frustrating by stupid
39 > faults in the layer below.
40 >
41 > If you think about it logically, you would EXPECT that the effort of
42 > indexing a file would be substantially less than that of reading it,
43 > wouldn't you? So why would you expect reading a bunch of files and
44 > indexing them would peg *cpu* use at 100%? Surely it's going to peg disk
45 > i/o at 100%?
47 I did but I was looking at it from the point that KDE and plasma was
48 triggering this.  After all, if KDE/plasma wasn't triggering this and
49 they did it the way KDE3 did, it wouldn't be a issue at all.  I'd rather
50 them go back and use that code/method regardless of whether the kernel
51 gets fixed or not.  That said, if the kernel has such a issue, it should
52 be fixed as well.  Thing is, the current way KDE5/plasma is doing this,
53 it isn't what I expected or would even want anyway.  It's no better than
54 the old fixed random method that we were stuck with since KDE3 went
55 away.  KDE3 did it in a logical way and worked, even tho it was old code. 
58 >> Maybe later on it will be fixed. It only took a couple years for them
59 >> to add anything non-random anyway. For ages, it was random and nothing
60 >> else. I just don't have the energy right now to add several thousand
61 >> directories to the dialog one at a time. o_O
62 >>
63 >> At least we figured out what the problem is. That's a start I guess. ;-)
64 >>
65 > Well, the fix should hopefully be in the next kernel release. It then
66 > needs Plasma to take advantage of it, which shouldn't be long ...
67 >
68 > Cheers,
69 > Wol
70 >
72 So that means I'd have to upgrade my kernel.  Well, it may fix some
73 other issue I'm not even aware of so maybe it isn't a bad deal.  Still,
74 just wish they would use the old method.  At least it worked like one
75 would expect.  ;-)
77 Dale
79 :-)  :-)