xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [for-4.9] Re: HVM guest performance regression
Date: Fri, 26 May 2017 19:00:24 +0200	[thread overview]
Message-ID: <2e6d9143-1abe-2f99-155f-f1071245ca41@suse.com> (raw)
In-Reply-To: <22824.21930.185651.403388@mariner.uk.xensource.com>

On 26/05/17 18:19, Ian Jackson wrote:
> Juergen Gross writes ("HVM guest performance regression"):
>> Looking for the reason of a performance regression of HVM guests under
>> Xen 4.7 against 4.5 I found the reason to be commit
>> c26f92b8fce3c9df17f7ef035b54d97cbe931c7a ("libxl: remove freemem_slack")
>> in Xen 4.6.
>>
>> The problem occurred when dom0 had to be ballooned down when starting
>> the guest. The performance of some micro benchmarks dropped by about
>> a factor of 2 with above commit.
>>
>> Interesting point is that the performance of the guest will depend on
>> the amount of free memory being available at guest creation time.
>> When there was barely enough memory available for starting the guest
>> the performance will remain low even if memory is being freed later.
>>
>> I'd like to suggest we either revert the commit or have some other
>> mechanism to try to have some reserve free memory when starting a
>> domain.
> 
> Oh, dear.  The memory accounting swamp again.  Clearly we are not
> going to drain that swamp now, but I don't like regressions.
> 
> I am not opposed to reverting that commit.  I was a bit iffy about it
> at the time; and according to the removal commit message, it was
> basically removed because it was a piece of cargo cult for which we
> had no justification in any of our records.
> 
> Indeed I think fixing this is a candidate for 4.9.
> 
> Do you know the mechanism by which the freemem slack helps ?  I think
> that would be a prerequisite for reverting this.  That way we can have
> an understanding of why we are doing things, rather than just
> flailing at random...

I wish I would understand it.

One candidate would be 2M/1G pages being possible with enough free
memory, but I haven't proofed this yet. I can have a try by disabling
big pages in the hypervisor.

What makes the whole problem even more mysterious is that the
regression was detected first with SLE12 SP3 (guest and dom0, Xen 4.9
and Linux 4.4) against older systems (guest and dom0). While trying
to find out whether the guest or the Xen version are the culprit I
found that the old guest (based on kernel 3.12) showed the mentioned
performance drop with above commit. The new guest (based on kernel
4.4) shows the same bad performance regardless of the Xen version or
amount of free memory. I haven't found the Linux kernel commit yet
being responsible for that performance drop.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2017-05-26 17:00 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-26 16:14 HVM guest performance regression Juergen Gross
2017-05-26 16:19 ` [for-4.9] " Ian Jackson
2017-05-26 17:00   ` Juergen Gross [this message]
2017-05-26 19:01     ` Stefano Stabellini
2017-05-29 19:05       ` Juergen Gross
2017-05-30  7:24         ` Jan Beulich
     [not found]         ` <592D3A3A020000780015D787@suse.com>
2017-05-30 10:33           ` Juergen Gross
2017-05-30 10:43             ` Jan Beulich
     [not found]             ` <592D68DC020000780015D919@suse.com>
2017-05-30 14:57               ` Juergen Gross
2017-05-30 15:10                 ` Jan Beulich
2017-06-06 13:44       ` Juergen Gross
2017-06-06 16:39         ` Stefano Stabellini
2017-06-06 19:00           ` Juergen Gross
2017-06-06 19:08             ` Stefano Stabellini
2017-06-07  6:55               ` Juergen Gross
2017-06-07 18:19                 ` Stefano Stabellini
2017-06-08  9:37                   ` Juergen Gross
2017-06-08 18:09                     ` Stefano Stabellini
2017-06-08 18:28                       ` Juergen Gross
2017-06-08 21:00                     ` Dario Faggioli
2017-06-11  2:27                       ` Konrad Rzeszutek Wilk
2017-06-12  5:48                       ` Solved: " Juergen Gross
2017-06-12  7:35                         ` Andrew Cooper
2017-06-12  7:47                           ` Juergen Gross
2017-06-12  8:30                             ` Andrew Cooper
2017-05-26 17:04 ` Dario Faggioli
2017-05-26 17:25   ` Juergen Gross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2e6d9143-1abe-2f99-155f-f1071245ca41@suse.com \
    --to=jgross@suse.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).