| 1 |
On 24/12/19 22:23, Dale wrote: |
| 2 |
> Wols Lists wrote: |
| 3 |
>> On 24/12/19 20:33, Dale wrote: |
| 4 |
>>> I think it is indexing/caching/something that requires it to look at |
| 5 |
>>> every single file in there plus all the levels below it. If so, that |
| 6 |
>>> would be a huge task. Here is some info on that but I did post it a bit |
| 7 |
>>> ago. It was sort of nested in one of the posts. |
| 8 |
>> Exactly. The thing about what this developer noticed is that it is the |
| 9 |
>> READING THE FILES that kills the system performance. The indexing is |
| 10 |
>> just random noise. |
| 11 |
>> |
| 12 |
>> So once this fix gets into the system it won't matter that it's indexing |
| 13 |
>> - the indexing will stall waiting for the files to be read, and reading |
| 14 |
>> the files won't kill the system. |
| 15 |
>> |
| 16 |
>> What seems to be happening at the moment is that as plasma reads the |
| 17 |
>> files, linux is paging plasma out to make way for the files, then it has |
| 18 |
>> to drop old cache to page plasma back in, and it's just got stuck in |
| 19 |
>> treacle trying to "in out in out shake it all about" :-) |
| 20 |
>> |
| 21 |
>> Cheers, |
| 22 |
>> Wol |
| 23 |
>> |
| 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 |
|
| 30 |
Apologies, but did you bother to read what I wrote? The fault has |
| 31 |
ABSOLUTELY NOTHING to do with Plasma or KDE. |
| 32 |
|
| 33 |
I'm inclined to agree that KDE should try and work round bugs, but the |
| 34 |
real fault lies in the Linux kernel. |
| 35 |
|
| 36 |
I'm a kernel dev wannabe, and following what's going on can be VERY |
| 37 |
enlightening - this is a design fault, and I'm sure there are plenty |
| 38 |
more ... :-) it can be VERY frustrating as an app developer to find that |
| 39 |
what *should* be nice and simple is made horribly frustrating by stupid |
| 40 |
faults in the layer below. |
| 41 |
|
| 42 |
If you think about it logically, you would EXPECT that the effort of |
| 43 |
indexing a file would be substantially less than that of reading it, |
| 44 |
wouldn't you? So why would you expect reading a bunch of files and |
| 45 |
indexing them would peg *cpu* use at 100%? Surely it's going to peg disk |
| 46 |
i/o at 100%? |
| 47 |
> |
| 48 |
> Maybe later on it will be fixed. It only took a couple years for them |
| 49 |
> to add anything non-random anyway. For ages, it was random and nothing |
| 50 |
> else. I just don't have the energy right now to add several thousand |
| 51 |
> directories to the dialog one at a time. o_O |
| 52 |
> |
| 53 |
> At least we figured out what the problem is. That's a start I guess. ;-) |
| 54 |
> |
| 55 |
Well, the fix should hopefully be in the next kernel release. It then |
| 56 |
needs Plasma to take advantage of it, which shouldn't be long ... |
| 57 |
|
| 58 |
Cheers, |
| 59 |
Wol |
Archives