reset priority

[petrossa]

Lately, can't say exactly after which build, i've had problems to reset the priority of processes which had been lowered by PL. I rightclick the processname, choose the priority (normal) but in the column nothing changes. Also i had quite a number of lowered processes (about 5).
I had one process crashing and taking out the 4 cores. I quess that since the 1 process took all the cores, PL calculated the resting load capacity and decided all running process where over the limit. I managed to get the runaway to quit, but after that the above happened

[Jeremy Collake]

That's strange. I recommend increasing the 'Per-process CPU usage when restraint should begin' to keep it from firing off on so many processes. It does that intentionally, with the thought that a temporary lowering of background process priorities won't hurt anything, so its better to be over-inclusive than under-exclusive. I may increase the default value though, perhaps it is too sensitive for most people. I'll work on that some today.

As for the priorities getting stuck in 'Below normal' and refusing to go back to 'Normal'... did you verify the priority classes in the task manager or process explorer? I'm starting to wonder if perhaps there is a GUI bug in Process Lasso, because I don't know how to explain the priorities not being restored, nor the inability to manually change the priorities to normal. If they were indeed not restored to normal and couldn't be manually set to normal, then I don't know what's going on. It could have been that the governor was continually lowering their priorities, if the system was still in a high load state.

I just don't know.. Keep in mind that once Process Lasso lowers a priority, it will stay that way for a minimum of 6 seconds, unless it becomes the foreground process and foreground exclusions are enabled. If it continues to use over 25% (current default) and the total CPU load is above 80% (current default), it will stay 'below normal'.

Update: I just did revise the default settings a little bit, they will be present in the next build.

[petrossa]

If i understand correctly lasso calculates the rest of the loadcapacity, so 25% threshold is based on the remaining loadcapacity? Not 25% of 100%, but 25% of the (let's say) 60% which is still available. In which case a process which runs at 20% totalcapacity will be lowered if totalcapacity is lower then 100% ?

[Jeremy Collake]

If i understand correctly lasso calculates the rest of the loadcapacity, so 25% threshold is based on the remaining loadcapacity? Not 25% of 100%, but 25% of the (let's say) 60% which is still available. In which case a process which runs at 20% totalcapacity will be lowered if totalcapacity is lower then 100% ?

Well, sort of . Process Lasso never uses the 'remainder of load capacity' - at least not directly.

There are two basic variables at play here:

1. Total CPU consumption by all processes combined
2. Total CPU consumption by a single process

The out-of-control restraint only kicks in if total CPU consumption is > 80% (now 85%). At which time, all processes that are using at least 25% (now 35%) of the total CPU cycles for a duration of at least X seconds will have their priorities temporarily lowered. I have no doubt that the 25/35% seems like an extraordinarily low value, but keep in mind that it represents sustained usage during a high-load scenario. In cases where there are multiple offending processes, it is necessary to 'hit' several of them, while leaving the foreground processes untouched. Note that even if foreground processes are NOT excluded from restraint, they are still handled differently than background processes so they won't get 'hit' with this 'heavy hammer'. It essentially takes more for a foreground process to 'set off' the process restraint mechanism.

Also, for multi-CPU systems, it isn't possible for a process with a single active thread to reach above 1/x of available CPU cycles since it is only running on one CPU. While this process wouldn't be hurting the performance on the other CPUs, there might be critical/active threads bound to the same CPU the offending thread is running on. So, that was a consideration too.

I raised the value to 35% only because I decided at some point Process Lasso might as well not even try. If there are that many offending processes, then I'm not sure how much of a difference Process Lasso will make.

I hope this makes sense. Sadly, there is no magic formula that works in 100% of cases. I try to approach it with an 'above all, do no harm' mentality.. and I think that works for me

[petrossa]

tnx for the explanation. makes sense. Anyroad i haven't been able to reproduce the problem consequently.
Just one observation: taken that in a multi-cpu a given process usually runs for the most part on a single cpu, taken that in an everyday normal usage system on average less then 4 processes run continously ( in my experience, rarely more then 2) the scenario there might be critical/active threads bound to the same CPU the offending thread is running on is rare enough to use the ostrich algorythm in that case.

[Jeremy Collake]

Just one observation: taken that in a multi-cpu a given process usually runs for the most part on a single cpu, taken that in an everyday normal usage system on average less then 4 processes run continously ( in my experience, rarely more then 2) the scenario there might be critical/active threads bound to the same CPU the offending thread is running on is rare enough to use the ostrich algorythm in that case.

Yes, you may be quite right about that -- one can't handle/improve every conceivable situation so maybe best to ignore rare ones. I think raising the per-process CPU threshold to 35% starts to do this. I dunno, I'm always working to find better defaults.

The one good thing is that it really doesn't hurt any background process to have its priority class temporarily lowered a little. So, if PL is over-active, that's probably ok.. and if it's under-active, well that's probably ok too .