From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751577AbbFAHgV (ORCPT ); Mon, 1 Jun 2015 03:36:21 -0400 Received: from e06smtp17.uk.ibm.com ([195.75.94.113]:40303 "EHLO e06smtp17.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751434AbbFAHgH (ORCPT ); Mon, 1 Jun 2015 03:36:07 -0400 Message-ID: <556C0B5D.40205@de.ibm.com> Date: Mon, 01 Jun 2015 09:35:57 +0200 From: Christian Borntraeger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Dominik Dingel , linux-kernel@vger.kernel.org CC: Russell King , Catalin Marinas , Will Deacon , Tony Luck , Fenghua Yu , James Hogan , Ralf Baechle , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Martin Schwidefsky , Heiko Carstens , linux390@de.ibm.com, "David S. Miller" , Chris Metcalf , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Andrew Morton , Zhang Zhen , David Rientjes , "Aneesh Kumar K.V" , Nathan Lynch , Andy Lutomirski , Michael Holzheu , Hugh Dickins , Naoya Horiguchi , Paolo Bonzini , "Jason J. Herne" , Davidlohr Bueso , "Kirill A. Shutemov" , Luiz Capitulino , Mike Kravetz , linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linux-metag@vger.kernel.org, linux-mips@linux-mips.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 0/5] Remove s390 sw-emulated hugepages and cleanup References: <1432813957-46874-1-git-send-email-dingel@linux.vnet.ibm.com> In-Reply-To: <1432813957-46874-1-git-send-email-dingel@linux.vnet.ibm.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15060107-0029-0000-0000-000004DE9CE9 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 28.05.2015 um 13:52 schrieb Dominik Dingel: > Hi everyone, > > there is a potential bug with KVM and hugetlbfs if the hardware does not > support hugepages (EDAT1). > We fix this by making EDAT1 a hard requirement for hugepages and > therefore removing and simplifying code. The cleanup itself is nice and probably the right thing to do. Emulating large pages makes the code more complex and asks for trouble (as outlined above) The only downside that I see is that z/VM as of today does not announce EDAT1 for its guests so the "emulated" large pages for hugetlbfs would be useful in that case. The current code allocates the page table only once and shares it for all mappers - which is useful for some big databases that spawn hundreds of processes with shared mappings of several hundred GBs. In these cases we do save a decent amount of page table memory. Not sure if that case is actually important, though. Christian