From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Schwidefsky Subject: Re: [PATCH] KVM: s390: remove delayed reallocation of page tables for KVM Date: Thu, 23 Apr 2015 14:13:09 +0200 Message-ID: <20150423141309.7c500236@mschwide> References: <1429787297-9292-1-git-send-email-borntraeger@de.ibm.com> <1429787297-9292-2-git-send-email-borntraeger@de.ibm.com> <2E97DEE6-47EA-484A-9F02-9F031DCA8F36@suse.de> <5538DAD4.4060505@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Christian Borntraeger , Paolo Bonzini , KVM , Cornelia Huck , Jens Freimann To: Alexander Graf Return-path: Received: from e06smtp12.uk.ibm.com ([195.75.94.108]:59408 "EHLO e06smtp12.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965539AbbDWMNQ (ORCPT ); Thu, 23 Apr 2015 08:13:16 -0400 Received: from /spool/local by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 23 Apr 2015 13:13:14 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 711351B08069 for ; Thu, 23 Apr 2015 13:13:49 +0100 (BST) Received: from d06av11.portsmouth.uk.ibm.com (d06av11.portsmouth.uk.ibm.com [9.149.37.252]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t3NCDC3D63897690 for ; Thu, 23 Apr 2015 12:13:12 GMT Received: from d06av11.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t3NCDBpK025537 for ; Thu, 23 Apr 2015 06:13:11 -0600 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Thu, 23 Apr 2015 14:01:23 +0200 Alexander Graf 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.