From: Dave Hansen <dave.hansen@intel.com> To: Cody P Schafer <cody@linux.vnet.ibm.com>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, Alex Thorlton <athorlton@sgi.com>, Ingo Molnar <mingo@redhat.com>, Andrew Morton <akpm@linux-foundation.org>, Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: "Eric W . Biederman" <ebiederm@xmission.com>, "Paul E . McKenney" <paulmck@linux.vnet.ibm.com>, Al Viro <viro@zeniv.linux.org.uk>, Andi Kleen <ak@linux.intel.com>, Andrea Arcangeli <aarcange@redhat.com>, Dave Jones <davej@redhat.com>, David Howells <dhowells@redhat.com>, Frederic Weisbecker <fweisbec@gmail.com>, Johannes Weiner <hannes@cmpxchg.org>, Kees Cook <keescook@chromium.org>, Mel Gorman <mgorman@suse.de>, Michael Kerrisk <mtk.manpages@gmail.com>, Oleg Nesterov <oleg@redhat.com>, Peter Zijlstra <peterz@infradead.org>, Rik van Riel <riel@redhat.com>, Robin Holt <robinmholt@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>, Srikar Dronamraju <srikar@linux.vnet.ibm.com>, Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCHv4 02/10] mm: convert mm->nr_ptes to atomic_t Date: Fri, 27 Sep 2013 14:01:22 -0700 [thread overview] Message-ID: <5245F222.1000603@intel.com> (raw) In-Reply-To: <5245EEAD.7010901@linux.vnet.ibm.com> On 09/27/2013 01:46 PM, Cody P Schafer wrote: > On 09/27/2013 06:16 AM, Kirill A. Shutemov wrote: >> @@ -339,6 +339,7 @@ struct mm_struct { >> pgd_t * pgd; >> atomic_t mm_users; /* How many users with user space? */ >> atomic_t mm_count; /* How many references to "struct >> mm_struct" (users count as 1) */ >> + atomic_t nr_ptes; /* Page table pages */ >> int map_count; /* number of VMAs */ ... > > Will 32bits always be enough here? Should atomic_long_t be used instead? There are 48 bits of virtual address space on x86 today. 12 bits of that is the address inside the page, so we've at *most* 2^36 pages. 2^9 (512) pages are mapped by a pte page, so that means the page tables only hold 2^27 pte pages in a single process. We've got 31 bits of usable space in the atomic_t, so that definitely works _today_. If the virtual address space ever gets bigger, we might have problems, though. In practice, though, we steal a big chunk of that virtual address space for the kernel, and that doesn't get accounted in mm->nr_ptes, so we've got a _bit_ more wiggle room than just 4 bits. Also, anybody that's mapping >4 petabytes of memory with 4k ptes is just off their rocker. I'm also not sure what the virtual address limits are for the more obscure architectures, so I guess it's also possible they'll hit this. I guess it wouldn't hurt to stick an overflow check in there for VM debugging purposes.
WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave.hansen@intel.com> To: Cody P Schafer <cody@linux.vnet.ibm.com>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, Alex Thorlton <athorlton@sgi.com>, Ingo Molnar <mingo@redhat.com>, Andrew Morton <akpm@linux-foundation.org>, Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: "Eric W . Biederman" <ebiederm@xmission.com>, "Paul E . McKenney" <paulmck@linux.vnet.ibm.com>, Al Viro <viro@zeniv.linux.org.uk>, Andi Kleen <ak@linux.intel.com>, Andrea Arcangeli <aarcange@redhat.com>, Dave Jones <davej@redhat.com>, David Howells <dhowells@redhat.com>, Frederic Weisbecker <fweisbec@gmail.com>, Johannes Weiner <hannes@cmpxchg.org>, Kees Cook <keescook@chromium.org>, Mel Gorman <mgorman@suse.de>, Michael Kerrisk <mtk.manpages@gmail.com>, Oleg Nesterov <oleg@redhat.com>, Peter Zijlstra <peterz@infradead.org>, Rik van Riel <riel@redhat.com>, Robin Holt <robinmholt@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>, Srikar Dronamraju <srikar@linux.vnet.ibm.com>, Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCHv4 02/10] mm: convert mm->nr_ptes to atomic_t Date: Fri, 27 Sep 2013 14:01:22 -0700 [thread overview] Message-ID: <5245F222.1000603@intel.com> (raw) In-Reply-To: <5245EEAD.7010901@linux.vnet.ibm.com> On 09/27/2013 01:46 PM, Cody P Schafer wrote: > On 09/27/2013 06:16 AM, Kirill A. Shutemov wrote: >> @@ -339,6 +339,7 @@ struct mm_struct { >> pgd_t * pgd; >> atomic_t mm_users; /* How many users with user space? */ >> atomic_t mm_count; /* How many references to "struct >> mm_struct" (users count as 1) */ >> + atomic_t nr_ptes; /* Page table pages */ >> int map_count; /* number of VMAs */ ... > > Will 32bits always be enough here? Should atomic_long_t be used instead? There are 48 bits of virtual address space on x86 today. 12 bits of that is the address inside the page, so we've at *most* 2^36 pages. 2^9 (512) pages are mapped by a pte page, so that means the page tables only hold 2^27 pte pages in a single process. We've got 31 bits of usable space in the atomic_t, so that definitely works _today_. If the virtual address space ever gets bigger, we might have problems, though. In practice, though, we steal a big chunk of that virtual address space for the kernel, and that doesn't get accounted in mm->nr_ptes, so we've got a _bit_ more wiggle room than just 4 bits. Also, anybody that's mapping >4 petabytes of memory with 4k ptes is just off their rocker. I'm also not sure what the virtual address limits are for the more obscure architectures, so I guess it's also possible they'll hit this. I guess it wouldn't hurt to stick an overflow check in there for VM debugging purposes. -- 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>
next prev parent reply other threads:[~2013-09-27 21:01 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-09-27 13:16 [PATCHv4 00/10] split page table lock for PMD tables Kirill A. Shutemov 2013-09-27 13:16 ` Kirill A. Shutemov 2013-09-27 13:16 ` [PATCHv4 01/10] mm: rename USE_SPLIT_PTLOCKS to USE_SPLIT_PTE_PTLOCKS Kirill A. Shutemov 2013-09-27 13:16 ` Kirill A. Shutemov 2013-09-27 13:16 ` [PATCHv4 02/10] mm: convert mm->nr_ptes to atomic_t Kirill A. Shutemov 2013-09-27 13:16 ` Kirill A. Shutemov 2013-09-27 20:46 ` Cody P Schafer 2013-09-27 20:46 ` Cody P Schafer 2013-09-27 21:01 ` Dave Hansen [this message] 2013-09-27 21:01 ` Dave Hansen 2013-09-27 22:24 ` Kirill A. Shutemov 2013-09-28 0:13 ` Johannes Weiner 2013-09-28 0:13 ` Johannes Weiner 2013-09-28 16:12 ` Kirill A. Shutemov 2013-09-27 13:16 ` [PATCHv4 03/10] mm: introduce api for split page table lock for PMD level Kirill A. Shutemov 2013-09-27 13:16 ` Kirill A. Shutemov 2013-09-27 13:16 ` [PATCHv4 04/10] mm, thp: change pmd_trans_huge_lock() to return taken lock Kirill A. Shutemov 2013-09-27 13:16 ` Kirill A. Shutemov 2013-09-27 13:16 ` [PATCHv4 05/10] mm, thp: move ptl taking inside page_check_address_pmd() Kirill A. Shutemov 2013-09-27 13:16 ` Kirill A. Shutemov 2013-09-27 13:16 ` [PATCHv4 06/10] mm, thp: do not access mm->pmd_huge_pte directly Kirill A. Shutemov 2013-09-27 13:16 ` Kirill A. Shutemov 2013-09-27 13:16 ` [PATCHv4 07/10] mm, hugetlb: convert hugetlbfs to use split pmd lock Kirill A. Shutemov 2013-09-27 13:16 ` Kirill A. Shutemov 2013-09-27 13:16 ` [PATCHv4 08/10] mm: convent the rest to new page table lock api Kirill A. Shutemov 2013-09-27 13:16 ` Kirill A. Shutemov 2013-09-27 13:16 ` [PATCHv4 09/10] mm: implement split page table lock for PMD level Kirill A. Shutemov 2013-09-27 13:16 ` Kirill A. Shutemov 2013-10-03 23:11 ` Andrew Morton 2013-10-03 23:11 ` Andrew Morton 2013-10-03 23:38 ` Kirill A. Shutemov 2013-10-03 23:38 ` Kirill A. Shutemov 2013-10-04 0:34 ` Kirill A. Shutemov 2013-10-04 7:21 ` Peter Zijlstra 2013-10-04 7:21 ` Peter Zijlstra 2013-10-03 23:42 ` Kirill A. Shutemov 2013-09-27 13:16 ` [PATCHv4 10/10] x86, mm: enable " Kirill A. Shutemov 2013-09-27 13:16 ` Kirill A. Shutemov 2013-10-04 20:12 ` [PATCHv4 00/10] split page table lock for PMD tables Alex Thorlton 2013-10-04 20:12 ` Alex Thorlton 2013-10-04 20:26 ` Kirill A. Shutemov 2013-10-04 20:26 ` Kirill A. Shutemov 2013-10-04 20:31 ` Alex Thorlton 2013-10-04 20:31 ` Alex Thorlton 2013-10-07 9:48 ` Kirill A. Shutemov 2013-10-07 9:48 ` Kirill A. Shutemov 2013-10-08 21:47 ` Alex Thorlton 2013-10-08 21:47 ` Alex Thorlton
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=5245F222.1000603@intel.com \ --to=dave.hansen@intel.com \ --cc=aarcange@redhat.com \ --cc=ak@linux.intel.com \ --cc=akpm@linux-foundation.org \ --cc=athorlton@sgi.com \ --cc=cody@linux.vnet.ibm.com \ --cc=davej@redhat.com \ --cc=dhowells@redhat.com \ --cc=ebiederm@xmission.com \ --cc=fweisbec@gmail.com \ --cc=hannes@cmpxchg.org \ --cc=keescook@chromium.org \ --cc=kirill.shutemov@linux.intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@suse.de \ --cc=mingo@redhat.com \ --cc=mtk.manpages@gmail.com \ --cc=n-horiguchi@ah.jp.nec.com \ --cc=oleg@redhat.com \ --cc=paulmck@linux.vnet.ibm.com \ --cc=peterz@infradead.org \ --cc=riel@redhat.com \ --cc=robinmholt@gmail.com \ --cc=sedat.dilek@gmail.com \ --cc=srikar@linux.vnet.ibm.com \ --cc=tglx@linutronix.de \ --cc=viro@zeniv.linux.org.uk \ /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: linkBe 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.