Re: [gentoo-user] KDE plasmashell and wallpapers.

[Dale]

Wols Lists wrote:
> On 24/12/19 22:23, Dale wrote:
>> Wols Lists wrote:
>>> On 24/12/19 20:33, Dale wrote:
>>>> I think it is indexing/caching/something that requires it to look at
>>>> every single file in there plus all the levels below it.  If so, that
>>>> would be a huge task. Here is some info on that but I did post it a bit
>>>> ago.  It was sort of nested in one of the posts.
>>> Exactly. The thing about what this developer noticed is that it is the
>>> READING THE FILES that kills the system performance. The indexing is
>>> just random noise.
>>>
>>> So once this fix gets into the system it won't matter that it's indexing
>>> - the indexing will stall waiting for the files to be read, and reading
>>> the files won't kill the system.
>>>
>>> What seems to be happening at the moment is that as plasma reads the
>>> files, linux is paging plasma out to make way for the files, then it has
>>> to drop old cache to page plasma back in, and it's just got stuck in
>>> treacle trying to "in out in out shake it all about" :-)
>>>
>>> Cheers,
>>> Wol
>>>
>>>
>> I suspect the dev that did this, has very few wallpapers or doesn't use
>> the feature at all and just has one pic he changes manually from time to
>> time.  lol
> Apologies, but did you bother to read what I wrote? The fault has
> ABSOLUTELY NOTHING to do with Plasma or KDE.
>
> I'm inclined to agree that KDE should try and work round bugs, but the
> real fault lies in the Linux kernel.
>
> I'm a kernel dev wannabe, and following what's going on can be VERY
> enlightening - this is a design fault, and I'm sure there are plenty
> more ... :-) it can be VERY frustrating as an app developer to find that
> what *should* be nice and simple is made horribly frustrating by stupid
> faults in the layer below.
>
> If you think about it logically, you would EXPECT that the effort of
> indexing a file would be substantially less than that of reading it,
> wouldn't you? So why would you expect reading a bunch of files and
> indexing them would peg *cpu* use at 100%? Surely it's going to peg disk
> i/o at 100%?

I did but I was looking at it from the point that KDE and plasma was
triggering this.  After all, if KDE/plasma wasn't triggering this and
they did it the way KDE3 did, it wouldn't be a issue at all.  I'd rather
them go back and use that code/method regardless of whether the kernel
gets fixed or not.  That said, if the kernel has such a issue, it should
be fixed as well.  Thing is, the current way KDE5/plasma is doing this,
it isn't what I expected or would even want anyway.  It's no better than
the old fixed random method that we were stuck with since KDE3 went
away.  KDE3 did it in a logical way and worked, even tho it was old code. 


>> Maybe later on it will be fixed.  It only took a couple years for them
>> to add anything non-random anyway.  For ages, it was random and nothing
>> else.  I just don't have the energy right now to add several thousand
>> directories to the dialog one at a time.  o_O
>>
>> At least we figured out what the problem is.  That's a start I guess.  ;-)
>>
> Well, the fix should hopefully be in the next kernel release. It then
> needs Plasma to take advantage of it, which shouldn't be long ...
>
> Cheers,
> Wol
>

So that means I'd have to upgrade my kernel.  Well, it may fix some
other issue I'm not even aware of so maybe it isn't a bad deal.  Still,
just wish they would use the old method.  At least it worked like one
would expect.  ;-)

Dale

:-)  :-)