Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1231530
| From | Dave Hansen <dave@sr71.net> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 11/15] mm, dax, pmem: introduce __pfn_t |
| Date | 2015-09-23 18:10 +0200 |
| Message-ID | <qbUMj-Eg-51@gated-at.bofh.it> (permalink) |
| References | <qbKae-20h-7@gated-at.bofh.it> <qbKae-20h-23@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 09/22/2015 09:42 PM, Dan Williams wrote:
> /*
> + * __pfn_t: encapsulates a page-frame number that is optionally backed
> + * by memmap (struct page). Whether a __pfn_t has a 'struct page'
> + * backing is indicated by flags in the low bits of the value;
> + */
> +typedef struct {
> + unsigned long val;
> +} __pfn_t;
> +
> +/*
> + * PFN_SG_CHAIN - pfn is a pointer to the next scatterlist entry
> + * PFN_SG_LAST - pfn references a page and is the last scatterlist entry
> + * PFN_DEV - pfn is not covered by system memmap by default
> + * PFN_MAP - pfn has a dynamic page mapping established by a device driver
> + */
> +enum {
> + PFN_SHIFT = 4,
> + PFN_MASK = (1UL << PFN_SHIFT) - 1,
> + PFN_SG_CHAIN = (1UL << 0),
> + PFN_SG_LAST = (1UL << 1),
> + PFN_DEV = (1UL << 2),
> + PFN_MAP = (1UL << 3),
> +};
Please forgive a little bikeshedding here...
Why __pfn_t? Because the KVM code has a pfn_t? If so, I think we
should rescue pfn_t from KVM and give them a kvm_pfn_t.
I think you should do one of two things: Make PFN_SHIFT 12 so that a
physical addr can be stored in a __pfn_t with no work. Or, use the
*high* 12 bits of __pfn_t.val.
If you use the high bits, *and* make it store a plain pfn when all the
bits are 0, then you get a zero-cost pfn<->__pfn_t conversion which will
hopefully generate the exact same code which is there today.
The one disadvantage here is that it makes it more likely that somebody
that's just setting __pfn_t.val=foo will get things subtly wrong
somehow, but that it will work most of the time.
Also, about naming... PFN_SHIFT is pretty awful name for this. It
probably needs to be __PFN_T_SOMETHING. We don't want folks doing
craziness like:
unsigned long phys_addr = pfn << PFN_SHIFT.
Which *looks* OK.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 11/15] mm, dax, pmem: introduce __pfn_t Dan Williams <dan.j.williams@intel.com> - 2015-09-23 06:50 +0200
Re: [PATCH 11/15] mm, dax, pmem: introduce __pfn_t Dave Hansen <dave@sr71.net> - 2015-09-23 18:10 +0200
Re: [PATCH 11/15] mm, dax, pmem: introduce __pfn_t "Williams, Dan J" <dan.j.williams@intel.com> - 2015-09-24 01:40 +0200
csiph-web