All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>,
	Matthew Wilcox <willy@linux.intel.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org, dave@sr71.net,
	riel@redhat.com, mgorman@suse.de, aarcange@redhat.com
Subject: Re: [RFC, PATCH] mm: unified interface to handle page table entries on different levels?
Date: Mon, 19 May 2014 23:46:32 +0530	[thread overview]
Message-ID: <87fvk5k51b.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140519002543.GA3899@node.dhcp.inet.fi>

"Kirill A. Shutemov" <kirill@shutemov.name> writes:

> On Sun, May 18, 2014 at 07:45:59PM -0400, Matthew Wilcox wrote:
>> On Sat, May 17, 2014 at 03:33:05AM +0300, Kirill A. Shutemov wrote:
>> > Below is my attempt to play with the problem. I've took one function --
>> > page_referenced_one() -- which looks ugly because of different APIs for
>> > PTE/PMD and convert it to use vpte_t. vpte_t is union for pte_t, pmd_t
>> > and pud_t.
>> > 
>> > Basically, the idea is instead of having different helpers to handle
>> > PTE/PMD/PUD, we have one, which take pair of vpte_t + pglevel.
>> 
>> I can't find my original attempt at this now (I am lost in a maze of
>> twisted git trees, all subtly different), but I called it a vpe (Virtual
>> Page Entry).
>> 
>> Rather than using a pair of vpte_t and pglevel, the vpe_t contained
>> enough information to discern what level it was; that's only two bits
>> and I think all the architectures have enough space to squeeze in two
>> more bits to the PTE (the PMD and PUD obviously have plenty of space).
>
> I'm not sure if it's possible to find a single free bit on all
> architectures. Two is near impossible.

On ppc64 we don't have any free bits.

>
> And what about 5-level page tables in future? Will we need 3 bits there?
> No way.

-aneesh

--
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: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>,
	Matthew Wilcox <willy@linux.intel.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org, dave@sr71.net,
	riel@redhat.com, mgorman@suse.de, aarcange@redhat.com
Subject: Re: [RFC, PATCH] mm: unified interface to handle page table entries on different levels?
Date: Mon, 19 May 2014 23:46:32 +0530	[thread overview]
Message-ID: <87fvk5k51b.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140519002543.GA3899@node.dhcp.inet.fi>

"Kirill A. Shutemov" <kirill@shutemov.name> writes:

> On Sun, May 18, 2014 at 07:45:59PM -0400, Matthew Wilcox wrote:
>> On Sat, May 17, 2014 at 03:33:05AM +0300, Kirill A. Shutemov wrote:
>> > Below is my attempt to play with the problem. I've took one function --
>> > page_referenced_one() -- which looks ugly because of different APIs for
>> > PTE/PMD and convert it to use vpte_t. vpte_t is union for pte_t, pmd_t
>> > and pud_t.
>> > 
>> > Basically, the idea is instead of having different helpers to handle
>> > PTE/PMD/PUD, we have one, which take pair of vpte_t + pglevel.
>> 
>> I can't find my original attempt at this now (I am lost in a maze of
>> twisted git trees, all subtly different), but I called it a vpe (Virtual
>> Page Entry).
>> 
>> Rather than using a pair of vpte_t and pglevel, the vpe_t contained
>> enough information to discern what level it was; that's only two bits
>> and I think all the architectures have enough space to squeeze in two
>> more bits to the PTE (the PMD and PUD obviously have plenty of space).
>
> I'm not sure if it's possible to find a single free bit on all
> architectures. Two is near impossible.

On ppc64 we don't have any free bits.

>
> And what about 5-level page tables in future? Will we need 3 bits there?
> No way.

-aneesh


  reply	other threads:[~2014-05-19 18:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-17  0:33 [RFC, PATCH] mm: unified interface to handle page table entries on different levels? Kirill A. Shutemov
2014-05-17  0:33 ` Kirill A. Shutemov
2014-05-18 23:45 ` Matthew Wilcox
2014-05-18 23:45   ` Matthew Wilcox
2014-05-19  0:25   ` Kirill A. Shutemov
2014-05-19  0:25     ` Kirill A. Shutemov
2014-05-19 18:16     ` Aneesh Kumar K.V [this message]
2014-05-19 18:16       ` Aneesh Kumar K.V

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=87fvk5k51b.fsf@linux.vnet.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave@sr71.net \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=riel@redhat.com \
    --cc=willy@linux.intel.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.