https://bugs.kde.org/show_bug.cgi?id=487459
--- Comment #3 from Roland <carbonwer...@hotmail.com> --- (In reply to Maik Qualmann from comment #1) > The jobs are processed in a QThreadPool; since Qt-6.2 it has been possible > to switch from "Normal" priority to a lower one or not to start threads with > all CPU cores available. > However, we then immediately have another bug report that digiKam would not > use all CPU cores. > > Problem is, I can't reproduce it here in a quick test with my 4-core laptop. > Windows can be used normally. > > Maik Hi Maik- I dont think I understand. What Im seeing is starvation avoidance- which is to say, Windows has a built-in fail safe for lower priority threads where they see 10-50ms of CPU time per 5 seconds or so. And depending on how complex the task is (i.e. a right click to bring up a menu), that may require several of those cycles- because it is creating new processes which themselves are running lower priority. So, this suggests that the engine is running in a config where it isnt sharing time with baseline tasks. During Duplicate finding, Im seeing 59 threads associated with the .exe, and all processors running at 100%. So, even at low priority, the app isnt being limited to some fraction of the cores or core cycles- it just defines how the scheduler prioritizes them. I wonder if this could be a function of how the CPU itself is setup- if for example, VT-x/IOMMU may play a role in how the OS is scheduling. But would it be possible to provide as a setting a value for Priority (Low vs Normal), so that people who are seeing this behavior dont have to run batch scripts or manually alter this? That might be an easier solution (to pass that as part of the procedure call) vs determining what is going on with the threading? If this is 100% repeatable here, and on another user's machine, and not on yours, its fair to say this impacts a fair number of users. I suspect that for many, they just assume that the process is slow and they accept that, or they are running smaller datasets (I have something like 300,000 images in play) where a 30 second 'blocking' process they see only infrequently just isnt impactful on their work. Best R -- You are receiving this mail because: You are watching all bug changes.
