From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Dominik Dingel <dingel@linux.vnet.ibm.com>, linux-kernel@vger.kernel.org
Cc: Russell King <linux@arm.linux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
James Hogan <james.hogan@imgtec.com>,
Ralf Baechle <ralf@linux-mips.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
linux390@de.ibm.com, "David S. Miller" <davem@davemloft.net>,
Chris Metcalf <cmetcalf@ezchip.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, Andrew Morton <akpm@linux-foundation.org>,
Zhang Zhen <zhenzhang.zhang@huawei.com>,
David Rientjes <rientjes@google.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Nathan Lynch <nathan_lynch@mentor.com>,
Andy Lutomirski <luto@amacapital.net>,
Michael Holzheu <holzheu@linux.vnet.ibm.com>,
Hugh Dickins <hughd@google.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
Paolo Bonzini <pbonzini@redhat.com>,
"Jason J. Herne" <jjherne@linux.vnet.ibm.com>,
Davidlohr Bueso <dave@stgolabs.net>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Luiz Capitulino <lcapitulino@redhat.com>,
Mike Kravetz <mike.kravetz@oracle.com>,
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
Date: Mon, 01 Jun 2015 09:35:57 +0200 [thread overview]
Message-ID: <556C0B5D.40205@de.ibm.com> (raw)
In-Reply-To: <1432813957-46874-1-git-send-email-dingel@linux.vnet.ibm.com>
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
next prev parent reply other threads:[~2015-06-01 7:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-28 11:52 [PATCH 0/5] Remove s390 sw-emulated hugepages and cleanup Dominik Dingel
2015-05-28 11:52 ` [PATCH 1/5] s390/mm: make hugepages_supported a boot time decision Dominik Dingel
2015-05-28 11:52 ` [PATCH 2/5] mm/hugetlb: remove unused arch hook prepare/release_hugepage Dominik Dingel
2015-05-28 11:52 ` [PATCH 3/5] mm/hugetlb: remove arch_prepare/release_hugepage from arch headers Dominik Dingel
2015-05-28 13:59 ` Ralf Baechle
2015-06-04 12:15 ` [3/5] " Michael Ellerman
2015-05-28 11:52 ` [PATCH 4/5] s390/hugetlb: remove dead code for sw emulated huge pages Dominik Dingel
2015-05-28 11:52 ` [PATCH 5/5] s390/mm: forward check for huge pmds to pmd_large() Dominik Dingel
2015-06-01 7:35 ` Christian Borntraeger [this message]
2015-06-02 7:46 ` [PATCH 0/5] Remove s390 sw-emulated hugepages and cleanup Dominik Dingel
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=556C0B5D.40205@de.ibm.com \
--to=borntraeger@de.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=catalin.marinas@arm.com \
--cc=cmetcalf@ezchip.com \
--cc=dave@stgolabs.net \
--cc=davem@davemloft.net \
--cc=dingel@linux.vnet.ibm.com \
--cc=fenghua.yu@intel.com \
--cc=heiko.carstens@de.ibm.com \
--cc=holzheu@linux.vnet.ibm.com \
--cc=hpa@zytor.com \
--cc=hughd@google.com \
--cc=james.hogan@imgtec.com \
--cc=jjherne@linux.vnet.ibm.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=lcapitulino@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-metag@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux390@de.ibm.com \
--cc=linux@arm.linux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=luto@amacapital.net \
--cc=mike.kravetz@oracle.com \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=nathan_lynch@mentor.com \
--cc=paulus@samba.org \
--cc=pbonzini@redhat.com \
--cc=ralf@linux-mips.org \
--cc=rientjes@google.com \
--cc=schwidefsky@de.ibm.com \
--cc=sparclinux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=will.deacon@arm.com \
--cc=x86@kernel.org \
--cc=zhenzhang.zhang@huawei.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 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).