Detailed throttling

[throttling]

ability to throttle a process that has multiple processes under it without process governor crashing.
add a drop cpu instructions upon ending throttle to prevent the cpu from trying to catch up on work it wasn't able to do while the cpu was throttled causing it to work harder.
add a lower throttle level or add a throttle by percentage option
add hard throttling and suspending process as options under the process watchdog. If possible add the amount of time the process is suspended for in seconds before resuming or an extremely high level of throttling that allows only very neglible cpu cycles.

[Jeremy Collake]

The throttling is indeed a neglected feature. I am not a big fan of it. However, in this time of maintenance, I will go ahead and rework the code, and allow it as a watchdog option.

add a drop cpu instructions upon ending throttle to prevent the cpu from trying to catch up on work it wasn't able to do while the cpu was throttled causing it to work harder.

I'm afraid this is impossible . Software doesn't work like that. You can't just 'throw out' instructions. There's no way of knowing what is critical and what isn't, or where to stop and where to resume execution at. Also, the code that would resume execution likely relies on the former code that got 'skipped'. You can't even reliably throw out missed messages sent to an application without causing all sorts of potential problems, and that's probably closer to what you're really wanting to do. Applications are simply not designed to allow this.

Throttle by % is a good idea, and seems more appropriate than the static ratios of suspend/resume time I currently use.

[BenYeeHua]

The throttling is indeed a neglected feature. I am not a big fan of it. However, in this time of maintenance, I will go ahead and rework the code, and allow it as a watchdog option.

Me too, except you are running many process that eating 100% of CPU, and the priority is not so perfect for that.

[hanemach_gt]

[...] and the priority is not so perfect for that.

I got it like you know better way?

http://bitsum.com/docs/pl/faq.htm#slow
http://bitsum.com/docs/pl/faq.htm#percent_request

[BenYeeHua]

I got it like you know better way?

http://bitsum.com/docs/pl/faq.htm#slow
http://bitsum.com/docs/pl/faq.htm#percent_request

What I means is, if you has 6-8 process set as "below normal" that don't affect the normal use, how can you make sure the important one get process first?(ya, maybe set it as low.)
And I has using some stress test tool, it lost performance after it has been set as "below normal" by Process Lasso, which I saw the power consumption drop nearly 60%, but it still showing 100% CPU usage.

I think maybe the cache is losing much when set as "below normal", and cause performance hit?

PS:Not enough sleep and don't try the function yet, just point out my error after you has try.

[hanemach_gt]

What I means is, if you has 6-8 process set as "below normal" that don't affect the normal use, how can you make sure the important one get process first?(ya, maybe set it as low.)
And I has using some stress test tool, it lost performance after it has been set as "below normal" by Process Lasso, which I saw the power consumption drop nearly 60%, but it still showing 100% CPU usage.

I think maybe the cache is losing much when set as "below normal", and cause performance hit?

PS:Not enough sleep and don't try the function yet, just point out my error after you has try.

I'm not into hardware<->software relations, I just threw what I've known from what Bitsum tells to the end user. It is indeed interesting, now I understand what you wanted to say.

I guess you are mistaken in some matter, I am not here to point or either hunt on anyone's errors and show how cool I am, because I am not cool or anything. If you felt offended at any point, I am sorry.

[Jeremy Collake]

I think maybe the cache is losing much when set as "below normal", and cause performance hit?

Could be, though I can't help but think the change in power consumption surely was exacerbated by other factors. The disruption caused by context switches is pretty hefty. Your caches tend get tossed away, and it's generally a very expensive operation. If the change in priority caused a large increase in context switches, then that might explain the situation. Benchmarks and stress tests are unique circumstances though, very few real applications operate the way they do. Of course, that's why ProBalance is set to ignore processes of non-normal priority, so it doesn't much with benchmarks and any other application that has specifically requested its priority class.

If you have multiple processes of the same priority class, then, individual thread priorities not withstanding, they should get access to the CPU nearly equally, with some precedence given to the foreground application (by Windows itself in the form of longer time slices). System components and other applications running at a Normal priority will take priority over a 'restrained' process, and thus
get the few CPU cycles they need to be responsive. This is why lowering the priorities works so well (instead of trying to raise the priorities of everything else).

In general, these days, with ever increasing number of cores, limiting a CPU by % is indeed possible through CPU affinity adjustments, as I mention in the FAQ article hanebach_gt pointed out. If your goal is such, that's definitely the preferred method. You're limited in granularity to 100/num_cores, but no method works better than that.

[BenYeeHua]

I'm not into hardware<->software relations, I just threw what I've known from what Bitsum tells to the end user. It is indeed interesting, now I understand what you wanted to say.

I guess you are mistaken in some matter, I am not here to point or either hunt on anyone's errors and show how cool I am, because I am not cool or anything. If you felt offended at any point, I am sorry.

lol, I just want to know the true, if you find any errors/mistaken, try to prove that I am wrong, and give me the real answer.
---
And yes, I am a little angry right now, but it is not cause by this forum, so I will not bring it here.

Could be, though I can't help but think the change in power consumption surely was exacerbated by other factors. The disruption caused by context switches is pretty hefty. Your caches tend get tossed away, and it's generally a very expensive operation. If the change in priority caused a large increase in context switches, then that might explain the situation. Benchmarks and stress tests are unique circumstances though, very few real applications operate the way they do. Of course, that's why ProBalance is set to ignore processes of non-normal priority, so it doesn't much with benchmarks and any other application that has specifically requested its priority class.

If you have multiple processes of the same priority class, then, individual thread priorities not withstanding, they should get access to the CPU nearly equally, with some precedence given to the foreground application (by Windows itself in the form of longer time slices). System components and other applications running at a Normal priority will take priority over a 'restrained' process, and thus
get the few CPU cycles they need to be responsive. This is why lowering the priorities works so well (instead of trying to raise the priorities of everything else).

In general, these days, with ever increasing number of cores, limiting a CPU by % is indeed possible through CPU affinity adjustments, as I mention in the FAQ article hanebach_gt pointed out. If your goal is such, that's definitely the preferred method. You're limited in granularity to 100/num_cores, but no method works better than that.

Yes, and I am thinking like this.
Core 0 for normal use like now, Core 1 give 80% for important process, 20% for not so important process.
But, the process don't switch way too much, it keep processing the important process until 80% of 1 sec, then 20% of 1 sec for not so important process.
So you don't switch too much and reduce the cache miss, but I think it only works for process that need Total output, not fastest short process time like game process.