From: Dave Hansen <dave.hansen@intel.com>
To: 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>
Cc: 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,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Sasha Levin <sasha.levin@oracle.com>
Subject: Re: [PATCH 2/4] mm: introduce new VM_NOZEROPAGE flag
Date: Fri, 17 Oct 2014 15:04:21 -0700 [thread overview]
Message-ID: <54419265.9000000@intel.com> (raw)
In-Reply-To: <1413554990-48512-3-git-send-email-dingel@linux.vnet.ibm.com>
On 10/17/2014 07:09 AM, Dominik Dingel wrote:
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index cd33ae2..8f09c91 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -113,7 +113,7 @@ extern unsigned int kobjsize(const void *objp);
> #define VM_GROWSDOWN 0x00000100 /* general info on the segment */
> #define VM_PFNMAP 0x00000400 /* Page-ranges managed without "struct page", just pure PFN */
> #define VM_DENYWRITE 0x00000800 /* ETXTBSY on write attempts.. */
> -
> +#define VM_NOZEROPAGE 0x00001000 /* forbid new zero page mappings */
> #define VM_LOCKED 0x00002000
> #define VM_IO 0x00004000 /* Memory mapped I/O or similar */
This seems like an awfully obscure use for a very constrained resource
(VM_ flags).
Is there ever a time where the VMAs under an mm have mixed VM_NOZEROPAGE
status? Reading the patches, it _looks_ like it might be an all or
nothing thing.
Full disclosure: I've got an x86-specific feature I want to steal a flag
for. Maybe we should just define another VM_ARCH bit.
--
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: Dave Hansen <dave.hansen@intel.com>
To: 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>
Cc: 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,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Sasha Levin <sasha.levin@oracle.com>
Subject: Re: [PATCH 2/4] mm: introduce new VM_NOZEROPAGE flag
Date: Fri, 17 Oct 2014 15:04:21 -0700 [thread overview]
Message-ID: <54419265.9000000@intel.com> (raw)
In-Reply-To: <1413554990-48512-3-git-send-email-dingel@linux.vnet.ibm.com>
On 10/17/2014 07:09 AM, Dominik Dingel wrote:
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index cd33ae2..8f09c91 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -113,7 +113,7 @@ extern unsigned int kobjsize(const void *objp);
> #define VM_GROWSDOWN 0x00000100 /* general info on the segment */
> #define VM_PFNMAP 0x00000400 /* Page-ranges managed without "struct page", just pure PFN */
> #define VM_DENYWRITE 0x00000800 /* ETXTBSY on write attempts.. */
> -
> +#define VM_NOZEROPAGE 0x00001000 /* forbid new zero page mappings */
> #define VM_LOCKED 0x00002000
> #define VM_IO 0x00004000 /* Memory mapped I/O or similar */
This seems like an awfully obscure use for a very constrained resource
(VM_ flags).
Is there ever a time where the VMAs under an mm have mixed VM_NOZEROPAGE
status? Reading the patches, it _looks_ like it might be an all or
nothing thing.
Full disclosure: I've got an x86-specific feature I want to steal a flag
for. Maybe we should just define another VM_ARCH bit.
next prev parent reply other threads:[~2014-10-17 22:04 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 [this message]
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
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=54419265.9000000@intel.com \
--to=dave.hansen@intel.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=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=kirill.shutemov@linux.intel.com \
--cc=konstantin.weitz@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux390@de.ibm.com \
--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=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=sasha.levin@oracle.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.