All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Alexander Graf <agraf@suse.de>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
	Paolo Bonzini <pbonzini@redhat.com>, KVM <kvm@vger.kernel.org>,
	Cornelia Huck <cornelia.huck@de.ibm.com>,
	Jens Freimann <jfrei@linux.vnet.ibm.com>
Subject: Re: [PATCH] KVM: s390: remove delayed reallocation of page tables for KVM
Date: Mon, 27 Apr 2015 15:57:45 +0200	[thread overview]
Message-ID: <20150427155745.64729393@mschwide> (raw)
In-Reply-To: <553E3E3A.9010107@suse.de>

On Mon, 27 Apr 2015 15:48:42 +0200
Alexander Graf <agraf@suse.de> wrote:

> On 04/23/2015 02:13 PM, Martin Schwidefsky wrote:
> > On Thu, 23 Apr 2015 14:01:23 +0200
> > Alexander Graf <agraf@suse.de> wrote:
> >
> >> As far as alternative approaches go, I don't have a great idea otoh.
> >> We could have an elf flag indicating that this process needs 4k page
> >> tables to limit the impact to a single process. In fact, could we
> >> maybe still limit the scope to non-global? A personality may work
> >> as well. Or ulimit?
> > I tried the ELF flag approach, does not work. The trouble is that
> > allocate_mm() has to create the page tables with 4K tables if you
> > want to change the page table layout later on. We have learned the
> > hard way that the direction 2K to 4K does not work due to races
> > in the mm.
> >
> > Now there are two major cases: 1) fork + execve and 2) fork only.
> > The ELF flag can be used to reduce from 4K to 2K for 1) but not 2).
> > 2) is required for apps that use lots of forking, e.g. database or
> > web servers. Same goes for the approach with a personality flag or
> > ulimit.
> >
> > We would have to distinguish the two cases for allocate_mm(),
> > if the new mm is allocated for a fork the current mm decides
> > 2K vs. 4K. If the new mm is allocated by binfmt_elf, then start
> > with 4K and do the downgrade after the ELF flag has been evaluated.
> 
> Well, you could also make it a personality flag for example, no? Then 
> every new process below a certain one always gets 4k page tables until 
> they drop the personality, at which point each child would only get 2k 
> page tables again.
> 
> I'm mostly concerned that people will end up mixing VMs and other 
> workloads on the same LPAR, so I don't think there's a one-shoe-fits-all 
> solution.

If I add an argument to mm_init() to indicate if this context
is for fork() or execve() then the ELF header flag approach works.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.


  parent reply	other threads:[~2015-04-27 13:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-23 11:08 [PATCH] page table bugfix for s390/kvm Christian Borntraeger
2015-04-23 11:08 ` [PATCH] KVM: s390: remove delayed reallocation of page tables for KVM Christian Borntraeger
2015-04-23 11:37   ` Alexander Graf
2015-04-23 11:43     ` Christian Borntraeger
2015-04-23 12:01       ` Alexander Graf
2015-04-23 12:08         ` Christian Borntraeger
2015-04-27 13:49           ` Alexander Graf
2015-04-23 12:13         ` Martin Schwidefsky
2015-04-27 13:48           ` Alexander Graf
2015-04-27 13:52             ` Paolo Bonzini
2015-04-27 13:57             ` Martin Schwidefsky [this message]
2015-04-27 14:03               ` Alexander Graf
2015-04-27 14:08                 ` Christian Borntraeger
2015-04-23 12:07       ` Paolo Bonzini
2015-04-23 13:57         ` Cole Robinson

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=20150427155745.64729393@mschwide \
    --to=schwidefsky@de.ibm.com \
    --cc=agraf@suse.de \
    --cc=borntraeger@de.ibm.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=jfrei@linux.vnet.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.