On 06/13/2018 11:43 PM, Dr. David Alan Gilbert wrote:
* Peter Xu (peterx@xxxxxxxxxx) wrote:
On Tue, Jun 12, 2018 at 10:42:25AM +0800, Xiao Guangrong wrote:
On 06/11/2018 03:39 PM, Peter Xu wrote:
On Mon, Jun 04, 2018 at 05:55:09PM +0800, guangrong.xiao@xxxxxxxxx wrote:
From: Xiao Guangrong <xiaoguangrong@xxxxxxxxxxx>
Instead of putting the main thread to sleep state to wait for
free compression thread, we can directly post it out as normal
page that reduces the latency and uses CPUs more efficiently
The feature looks good, though I'm not sure whether we should make a
capability flag for this feature since otherwise it'll be hard to
switch back to the old full-compression way no matter for what
reason. Would that be a problem?
We assume this optimization should always be optimistic for all cases,
particularly, we introduced the statistics of compression, then the user
should adjust its parameters based on those statistics if anything works
worse.
Ah, that'll be good.
Furthermore, we really need to improve this optimization if it hurts
any case rather than leaving a option to the user. :)
Yeah, even if we make it a parameter/capability we can still turn that
on by default in new versions but keep the old behavior in old
versions. :) The major difference is that, then we can still _have_ a
way to compress every page. I'm just thinking if we don't have a
switch for that then if someone wants to measure e.g. how a new
compression algo could help VM migration, then he/she won't be
possible to do that again since the numbers will be meaningless if
that bit is out of control on which page will be compressed.
Though I don't know how much use it'll bring... But if that won't be
too hard, it still seems good. Not a strong opinion.
I think that is needed; it might be that some users have really awful
networking and need the compression; I'd expect that for people who turn
on compression they really expect the slowdown because they need it for
their network, so changing that is a bit odd.
People should make sure the system has enough CPU resource to do
compression as well, so the perfect usage is that the 'busy-rate'
is low enough i think.
However, it's not a big deal, i will introduce a parameter,
maybe, compress-wait-free-thread.
Thank you all, Dave and Peter! :)
