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: Thu, 23 Apr 2015 14:13:09 +0200	[thread overview]
Message-ID: <20150423141309.7c500236@mschwide> (raw)
In-Reply-To: <E97BD94D-88F9-4B99-A5E4-D707DC0E2325@suse.de>

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.

-- 
blue skies,
   Martin.

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


  parent reply	other threads:[~2015-04-23 12:13 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 [this message]
2015-04-27 13:48           ` Alexander Graf
2015-04-27 13:52             ` Paolo Bonzini
2015-04-27 13:57             ` Martin Schwidefsky
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=20150423141309.7c500236@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.