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 :-) :-)
