From: Dan Williams <dan.j.williams@intel.com>
To: Matthew Wilcox <matthew.r.wilcox@intel.com>
Cc: Linux MM <linux-mm@kvack.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>
Subject: Re: [PATCH 1/3] pfn_t: Change the encoding
Date: Fri, 11 Mar 2016 13:40:20 -0800 [thread overview]
Message-ID: <CAPcyv4g82US298_mCd75toj9kEeyDhw0cP_Ott0R8fOydWNsSg@mail.gmail.com> (raw)
In-Reply-To: <1457730784-9890-2-git-send-email-matthew.r.wilcox@intel.com>
On Fri, Mar 11, 2016 at 1:13 PM, Matthew Wilcox
<matthew.r.wilcox@intel.com> wrote:
> By moving the flag bits to the bottom, we encourage commonality
> between SGs with pages and those using pfn_t. We can also then insert
> a pfn_t into a radix tree, as it uses the same two bits for indirect &
> exceptional indicators.
It's not immediately clear to me what we gain with SG entry
commonality. The down side is that we lose the property that
pfn_to_pfn_t() is a nop. This was Dave's suggestion so that the
nominal case did not change the binary layout of a typical pfn.
Can we just bit swizzle a pfn_t on insertion/retrieval from the radix?
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com>
To: Matthew Wilcox <matthew.r.wilcox@intel.com>
Cc: "linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>,
Matthew Wilcox <willy@linux.intel.com>,
Dave Hansen <dave.hansen@linux.intel.com>
Subject: Re: [PATCH 1/3] pfn_t: Change the encoding
Date: Fri, 11 Mar 2016 13:40:20 -0800 [thread overview]
Message-ID: <CAPcyv4g82US298_mCd75toj9kEeyDhw0cP_Ott0R8fOydWNsSg@mail.gmail.com> (raw)
In-Reply-To: <1457730784-9890-2-git-send-email-matthew.r.wilcox@intel.com>
On Fri, Mar 11, 2016 at 1:13 PM, Matthew Wilcox
<matthew.r.wilcox@intel.com> wrote:
> By moving the flag bits to the bottom, we encourage commonality
> between SGs with pages and those using pfn_t. We can also then insert
> a pfn_t into a radix tree, as it uses the same two bits for indirect &
> exceptional indicators.
It's not immediately clear to me what we gain with SG entry
commonality. The down side is that we lose the property that
pfn_to_pfn_t() is a nop. This was Dave's suggestion so that the
nominal case did not change the binary layout of a typical pfn.
Can we just bit swizzle a pfn_t on insertion/retrieval from the radix?
WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com>
To: Matthew Wilcox <matthew.r.wilcox@intel.com>
Cc: "linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>,
Matthew Wilcox <willy@linux.intel.com>,
Dave Hansen <dave.hansen@linux.intel.com>
Subject: Re: [PATCH 1/3] pfn_t: Change the encoding
Date: Fri, 11 Mar 2016 13:40:20 -0800 [thread overview]
Message-ID: <CAPcyv4g82US298_mCd75toj9kEeyDhw0cP_Ott0R8fOydWNsSg@mail.gmail.com> (raw)
In-Reply-To: <1457730784-9890-2-git-send-email-matthew.r.wilcox@intel.com>
On Fri, Mar 11, 2016 at 1:13 PM, Matthew Wilcox
<matthew.r.wilcox@intel.com> wrote:
> By moving the flag bits to the bottom, we encourage commonality
> between SGs with pages and those using pfn_t. We can also then insert
> a pfn_t into a radix tree, as it uses the same two bits for indirect &
> exceptional indicators.
It's not immediately clear to me what we gain with SG entry
commonality. The down side is that we lose the property that
pfn_to_pfn_t() is a nop. This was Dave's suggestion so that the
nominal case did not change the binary layout of a typical pfn.
Can we just bit swizzle a pfn_t on insertion/retrieval from the radix?
--
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:[~2016-03-11 21:40 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-11 21:13 [PATCH 0/3] Make pfn_t suitable for placing in the radix tree Matthew Wilcox
2016-03-11 21:13 ` Matthew Wilcox
2016-03-11 21:13 ` Matthew Wilcox
2016-03-11 21:13 ` [PATCH 1/3] pfn_t: Change the encoding Matthew Wilcox
2016-03-11 21:13 ` Matthew Wilcox
2016-03-11 21:13 ` Matthew Wilcox
2016-03-11 21:40 ` Dan Williams [this message]
2016-03-11 21:40 ` Dan Williams
2016-03-11 21:40 ` Dan Williams
2016-03-12 18:30 ` Matthew Wilcox
2016-03-12 18:30 ` Matthew Wilcox
2016-03-12 18:30 ` Matthew Wilcox
2016-03-13 23:09 ` Dan Williams
2016-03-13 23:09 ` Dan Williams
2016-03-13 23:09 ` Dan Williams
2016-03-14 15:00 ` Matthew Wilcox
2016-03-14 15:00 ` Matthew Wilcox
2016-03-14 15:00 ` Matthew Wilcox
2016-03-11 21:13 ` [PATCH 2/3] pfn_t: Support for huge PFNs Matthew Wilcox
2016-03-11 21:13 ` Matthew Wilcox
2016-03-11 21:13 ` Matthew Wilcox
2016-03-11 21:13 ` [PATCH 3/3] pfn_t: New functions pfn_t_add and pfn_t_cmp Matthew Wilcox
2016-03-11 21:13 ` Matthew Wilcox
2016-03-11 21:13 ` Matthew Wilcox
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=CAPcyv4g82US298_mCd75toj9kEeyDhw0cP_Ott0R8fOydWNsSg@mail.gmail.com \
--to=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=matthew.r.wilcox@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.