All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
	Dominik Dingel <dingel@linux.vnet.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, Mel Gorman <mgorman@suse.de>,
	Michal Hocko <mhocko@suse.cz>, Rik van Riel <riel@redhat.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Andy Lutomirski <luto@amacapital.net>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	Bob Liu <lliubbo@gmail.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Cornelia Huck <cornelia.huck@de.ibm.com>,
	Gleb Natapov <gleb@kernel.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Hugh Dickins <hughd@google.com>, Ingo Molnar <mingo@kernel.org>,
	Jianyu Zhan <nasa4836@gmail.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	"Kirill A. Shutemov" <kirill.shute
Subject: Re: [PATCH 2/4] mm: introduce new VM_NOZEROPAGE flag
Date: Tue, 21 Oct 2014 10:11:43 +0200	[thread overview]
Message-ID: <5446153F.6030407@redhat.com> (raw)
In-Reply-To: <20141021081131.641c6104@mschwide>



On 10/21/2014 08:11 AM, Martin Schwidefsky wrote:
>> I agree with Dave (I thought I disagreed, but I changed my mind while
>> writing down my thoughts).  Just define mm_forbids_zeropage in
>> arch/s390/include/asm, and make it return mm->context.use_skey---with a
>> comment explaining how this is only for processes that use KVM, and then
>> only for guests that use storage keys.
>
> The mm_forbids_zeropage() sure will work for now, but I think a vma flag
> is the better solution. This is analog to VM_MERGEABLE or VM_NOHUGEPAGE,
> the best solution would be to only mark those vmas that are mapped to
> the guest. That we have not found a way to do that yet in a sensible way
> does not change the fact that "no-zero-page" is a per-vma property, no?

I agree it should be per-VMA.  However, right now the code is 
complicated unnecessarily by making it a per-VMA flag.  Also, setting 
the flag per VMA should probably be done in 
kvm_arch_prepare_memory_region together with some kind of storage key 
notifier.  This is not very much like Dominik's patch.  All in all, 
mm_forbids_zeropage() provides a non-intrusive and non-controversial way 
to fix the bug.  Later on, switching to vma_forbids_zeropage() will be 
trivial as far as mm/ code is concerned.

> But if you insist we go with the mm_forbids_zeropage() until we find a
> clever way to distinguish the guest vmas from the qemu ones.

Yeah, I think it is simpler for now.

Paolo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
	Dominik Dingel <dingel@linux.vnet.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, Mel Gorman <mgorman@suse.de>,
	Michal Hocko <mhocko@suse.cz>, Rik van Riel <riel@redhat.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Andy Lutomirski <luto@amacapital.net>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	Bob Liu <lliubbo@gmail.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Cornelia Huck <cornelia.huck@de.ibm.com>,
	Gleb Natapov <gleb@kernel.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Hugh Dickins <hughd@google.com>, Ingo Molnar <mingo@kernel.org>,
	Jianyu Zhan <nasa4836@gmail.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Konstantin Weitz <konstantin.weitz@gmail.com>,
	kvm@vger.kernel.org, linux390@de.ibm.com,
	linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Sasha Levin <sasha.levin@oracle.com>
Subject: Re: [PATCH 2/4] mm: introduce new VM_NOZEROPAGE flag
Date: Tue, 21 Oct 2014 10:11:43 +0200	[thread overview]
Message-ID: <5446153F.6030407@redhat.com> (raw)
In-Reply-To: <20141021081131.641c6104@mschwide>



On 10/21/2014 08:11 AM, Martin Schwidefsky wrote:
>> I agree with Dave (I thought I disagreed, but I changed my mind while
>> writing down my thoughts).  Just define mm_forbids_zeropage in
>> arch/s390/include/asm, and make it return mm->context.use_skey---with a
>> comment explaining how this is only for processes that use KVM, and then
>> only for guests that use storage keys.
>
> The mm_forbids_zeropage() sure will work for now, but I think a vma flag
> is the better solution. This is analog to VM_MERGEABLE or VM_NOHUGEPAGE,
> the best solution would be to only mark those vmas that are mapped to
> the guest. That we have not found a way to do that yet in a sensible way
> does not change the fact that "no-zero-page" is a per-vma property, no?

I agree it should be per-VMA.  However, right now the code is 
complicated unnecessarily by making it a per-VMA flag.  Also, setting 
the flag per VMA should probably be done in 
kvm_arch_prepare_memory_region together with some kind of storage key 
notifier.  This is not very much like Dominik's patch.  All in all, 
mm_forbids_zeropage() provides a non-intrusive and non-controversial way 
to fix the bug.  Later on, switching to vma_forbids_zeropage() will be 
trivial as far as mm/ code is concerned.

> But if you insist we go with the mm_forbids_zeropage() until we find a
> clever way to distinguish the guest vmas from the qemu ones.

Yeah, I think it is simpler for now.

Paolo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
	Dominik Dingel <dingel@linux.vnet.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, Mel Gorman <mgorman@suse.de>,
	Michal Hocko <mhocko@suse.cz>, Rik van Riel <riel@redhat.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Andy Lutomirski <luto@amacapital.net>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	Bob Liu <lliubbo@gmail.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Cornelia Huck <cornelia.huck@de.ibm.com>,
	Gleb Natapov <gleb@kernel.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Hugh Dickins <hughd@google.com>, Ingo Molnar <mingo@kernel.org>,
	Jianyu Zhan <nasa4836@gmail.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Konstantin Weitz <konstantin.weitz@gmail.com>,
	kvm@vger.kernel.org, linux390@de.ibm.com,
	linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Sasha Levin <sasha.levin@oracle.com>
Subject: Re: [PATCH 2/4] mm: introduce new VM_NOZEROPAGE flag
Date: Tue, 21 Oct 2014 10:11:43 +0200	[thread overview]
Message-ID: <5446153F.6030407@redhat.com> (raw)
In-Reply-To: <20141021081131.641c6104@mschwide>



On 10/21/2014 08:11 AM, Martin Schwidefsky wrote:
>> I agree with Dave (I thought I disagreed, but I changed my mind while
>> writing down my thoughts).  Just define mm_forbids_zeropage in
>> arch/s390/include/asm, and make it return mm->context.use_skey---with a
>> comment explaining how this is only for processes that use KVM, and then
>> only for guests that use storage keys.
>
> The mm_forbids_zeropage() sure will work for now, but I think a vma flag
> is the better solution. This is analog to VM_MERGEABLE or VM_NOHUGEPAGE,
> the best solution would be to only mark those vmas that are mapped to
> the guest. That we have not found a way to do that yet in a sensible way
> does not change the fact that "no-zero-page" is a per-vma property, no?

I agree it should be per-VMA.  However, right now the code is 
complicated unnecessarily by making it a per-VMA flag.  Also, setting 
the flag per VMA should probably be done in 
kvm_arch_prepare_memory_region together with some kind of storage key 
notifier.  This is not very much like Dominik's patch.  All in all, 
mm_forbids_zeropage() provides a non-intrusive and non-controversial way 
to fix the bug.  Later on, switching to vma_forbids_zeropage() will be 
trivial as far as mm/ code is concerned.

> But if you insist we go with the mm_forbids_zeropage() until we find a
> clever way to distinguish the guest vmas from the qemu ones.

Yeah, I think it is simpler for now.

Paolo

  reply	other threads:[~2014-10-21  8:11 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-17 14:09 [PATCH 0/4] mm: new flag to forbid zero page mappings for a vma Dominik Dingel
2014-10-17 14:09 ` Dominik Dingel
2014-10-17 14:09 ` Dominik Dingel
2014-10-17 14:09 ` Dominik Dingel
2014-10-17 14:09 ` [PATCH 1/4] s390/mm: recfactor global pgste updates Dominik Dingel
2014-10-17 14:09   ` Dominik Dingel
2014-10-17 14:09   ` Dominik Dingel
2014-10-17 14:09 ` [PATCH 2/4] mm: introduce new VM_NOZEROPAGE flag Dominik Dingel
2014-10-17 14:09   ` Dominik Dingel
2014-10-17 14:09   ` Dominik Dingel
2014-10-17 14:09   ` Dominik Dingel
2014-10-17 22:04   ` Dave Hansen
2014-10-17 22:04     ` Dave Hansen
2014-10-18 14:49     ` Dominik Dingel
2014-10-18 14:49       ` Dominik Dingel
2014-10-18 14:49       ` Dominik Dingel
2014-10-18 16:28       ` Dave Hansen
2014-10-18 16:28         ` Dave Hansen
2014-10-18 16:28         ` Dave Hansen
2014-10-20 18:14         ` Paolo Bonzini
2014-10-20 18:14           ` Paolo Bonzini
2014-10-20 18:14           ` Paolo Bonzini
2014-10-21  6:11           ` Martin Schwidefsky
2014-10-21  6:11             ` Martin Schwidefsky
2014-10-21  6:11             ` Martin Schwidefsky
2014-10-21  8:11             ` Paolo Bonzini [this message]
2014-10-21  8:11               ` Paolo Bonzini
2014-10-21  8:11               ` Paolo Bonzini
2014-10-21 11:20               ` Dominik Dingel
2014-10-21 11:20                 ` Dominik Dingel
2014-10-21 11:20                 ` Dominik Dingel
2014-10-17 14:09 ` [PATCH 3/4] s390/mm: prevent and break zero page mappings in case of storage keys Dominik Dingel
2014-10-17 14:09   ` Dominik Dingel
2014-10-17 14:09   ` Dominik Dingel
2014-10-17 14:09   ` Dominik Dingel
2014-10-17 14:09 ` [PATCH 4/4] s390/mm: disable KSM for storage key enabled pages Dominik Dingel
2014-10-17 14:09   ` Dominik Dingel
2014-10-17 14:09   ` 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=5446153F.6030407@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=dave.hansen@intel.com \
    --cc=dingel@linux.vnet.ibm.com \
    --cc=gleb@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hpa@linux.intel.com \
    --cc=hughd@google.com \
    --cc=linux-mm@kvack.org \
    --cc=lliubbo@gmail.com \
    --cc=luto@amacapital.net \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.cz \
    --cc=mingo@kernel.org \
    --cc=nasa4836@gmail.com \
    --cc=riel@redhat.com \
    --cc=schwidefsky@de.ibm.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.