RE: [RFC 00/10] KVM: Add TMEM host/guest support

[Dan Magenheimer <dan.magenheimer@oracle.com>]

> From: Avi Kivity [mailto:avi@redhat.com]
> Subject: Re: [RFC 00/10] KVM: Add TMEM host/guest support

I started off with a point-by-point comment on most of your
responses about the tradeoffs of how tmem works, but decided
it best to simply say we disagree and kvm-tmem will need to
prove who is right.

> >> Sorry, no, first demonstrate no performance regressions, then we can
> >> talk about performance improvements.
> >
> > Well that's an awfully hard bar to clear, even with any of the many
> > changes being merged every release into the core Linux mm subsystem.
> > Any change to memory management will have some positive impacts on some
> > workloads and some negative impacts on others.
> 
> Right, that's too harsh.  But these benchmarks show a doubling (or even
> more) of cpu overhead, and that is whether the cache is effective or
> not.  That is simply way too much to consider.

One point here... remember you have contrived a worst case
scenario.  The one case Sasha provided outside of that contrived
worst case, as you commented, looks very nice.  So the costs/benefits
remain to be seen over a wider set of workloads.

Also, even that contrived case should look quite a bit better
with WasActive properly implemented.

> Look at the block, vfs, and mm layers.  Huge pains have been taken to
> batch everything and avoid per-page work -- 20 years of not having
> enough cycles.  And here you throw all this out of the window with
> per-page crossing of the guest/host boundary.

Well, to be fair, those 20 years of effort were because
(1) disk seeks are a million times slower than an in-RAM page
copy and (2) SMP systems were rare and expensive.  The
world changes...