Dan Williams writes:
> The current powerpc definition of vma_mmu_pagesize() open codes looking
> up the page size via hstate. It is identical to the generic
> vma_kernel_pagesize() implementation.
>
> Now, vma_kernel_pagesize() is growing support for determining the
> page size of Device-DAX vmas
Dynamic debug can be instructed to add the function name to the debug
output using the +f switch, so there is no need for the nfit module to
do it again. If a user decides to add the +f switch for nfit's dynamic
debug this results in double prints of the function name like the
following:
[ 2391.93
On Thu, Mar 01, 2018 at 11:53:16PM +, Stephen Bates wrote:
> > There's a meaningful difference between writing to an NVMe CMB vs PMR
>
> When the PMR spec becomes public we can discuss how best to integrate it into
> the P2P framework (if at all) ;-).
http://nvmexpress.org/wp-content/upload
On Fri, 2018-03-02 at 09:34 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2018-03-01 at 14:31 -0800, Linus Torvalds wrote:
> > On Thu, Mar 1, 2018 at 2:06 PM, Benjamin Herrenschmidt
> > wrote:
> > >
> > > Could be that x86 has the smarts to do the right thing, still trying to
> > > untangle the
On Fri, Mar 2, 2018 at 8:22 AM, Kani, Toshi wrote:
>
> FWIW, this thing is called MTRRs on x86, which are initialized by BIOS.
No.
Or rather, that's simply just another (small) part of it all - and an
architected and documented one at that.
Like the page table caching entries, the memory type r
On 02/03/18 09:18 AM, Jason Gunthorpe wrote:
This allocator is already seems not useful for the P2P target memory
on a Mellanox NIC due to the way it has a special allocation flow
(windowing) and special usage requirements..
Nor can it be usefull for the doorbell memory in the NIC.
No one s
On Fri, Mar 2, 2018 at 8:57 AM, Linus Torvalds
wrote:
>
> Like the page table caching entries, the memory type range registers
> are really just "secondary information". They don't actually select
> between PCIe and RAM, they just affect the behavior on top of that.
Side note: historically the tw
On Fri, 2018-03-02 at 08:57 -0800, Linus Torvalds wrote:
> On Fri, Mar 2, 2018 at 8:22 AM, Kani, Toshi wrote:
> >
> > FWIW, this thing is called MTRRs on x86, which are initialized by BIOS.
>
> No.
>
> Or rather, that's simply just another (small) part of it all - and an
> architected and docum
On Thu, Mar 01, 2018 at 07:53:44PM -0800, Dan Williams wrote:
> The current IS_DAX() helper that checks if a file is in DAX mode serves
> two purposes. It is a control flow branch condition for DAX vs
> non-DAX paths and it is a mechanism to perform dead code elimination. The
> dead code eliminatio
On Thu, Mar 01, 2018 at 07:54:16PM -0800, Dan Williams wrote:
> In preparation for fixing the broken definition of S_DAX in the
> CONFIG_FS_DAX=n + CONFIG_DEV_DAX=y case, convert all IS_DAX() usages to
> use explicit tests for FSDAX since DAX is ambiguous.
>
> Cc: "Darrick J. Wong"
> Cc: linux-..
On Fri, Mar 2, 2018 at 9:45 AM, Darrick J. Wong wrote:
> On Thu, Mar 01, 2018 at 07:53:44PM -0800, Dan Williams wrote:
>> The current IS_DAX() helper that checks if a file is in DAX mode serves
>> two purposes. It is a control flow branch condition for DAX vs
>> non-DAX paths and it is a mechanism
The current IS_DAX() helper that checks if a file is in DAX mode serves
two purposes. It is a control flow branch condition for DAX vs
non-DAX paths and it is a mechanism to perform dead code elimination. The
dead code elimination is required in the CONFIG_FS_DAX=n case since
there are symbols in f
On Fri, Mar 02, 2018 at 11:06:36AM -0800, Dan Williams wrote:
> The current IS_DAX() helper that checks if a file is in DAX mode serves
> two purposes. It is a control flow branch condition for DAX vs
> non-DAX paths and it is a mechanism to perform dead code elimination. The
> dead code eliminatio
>http://nvmexpress.org/wp-content/uploads/NVM-Express-1.3-Ratified-TPs.zip
@Keith - my apologies.
@Christoph - thanks for the link
So my understanding of when the technical content surrounding new NVMe
Technical Proposals (TPs) was wrong. I though the TP content could only be
discussed onc
> It seems people miss-understand HMM :(
Hi Jerome
Your unhappy face emoticon made me sad so I went off to (re)read up on HMM.
Along the way I came up with a couple of things.
While hmm.txt is really nice to read it makes no mention of DEVICE_PRIVATE and
DEVICE_PUBLIC. It also gives no indica
On Fri, 2018-03-02 at 10:25 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2018-03-01 at 16:19 -0700, Logan Gunthorpe wrote:
> >
> > On 01/03/18 04:00 PM, Benjamin Herrenschmidt wrote:
> > > We use only 52 in practice but yes.
> > >
> > > > That's 64PB. If you use need
> > > > a sparse vmemmap
I really don't like these IS_DEVDAX and IS_FSDAX flags. We should
stop pretending DAX is a global per-inode choice and get rid of these
magic flags entirely. So please convert the instances inside the
various file systems to checking the file system mount options instead.
For the core ones we'll
On Fri, Mar 02, 2018 at 09:38:43PM +, Stephen Bates wrote:
> > It seems people miss-understand HMM :(
>
> Hi Jerome
>
> Your unhappy face emoticon made me sad so I went off to (re)read up
> on HMM. Along the way I came up with a couple of things.
>
> While hmm.txt is really nice to read it
On Fri, Mar 2, 2018 at 2:10 PM, Christoph Hellwig wrote:
> I really don't like these IS_DEVDAX and IS_FSDAX flags. We should
> stop pretending DAX is a global per-inode choice and get rid of these
> magic flags entirely. So please convert the instances inside the
> various file systems to checki
On 02/03/18 02:44 PM, Benjamin Herrenschmidt wrote:
Allright, so, I think I have a plan to fix this, but it will take a
little bit of time.
Basically the idea is to have firmware pass to Linux a region that's
known to not have anything in it that it can use for the vmalloc space
rather than ha
On Thu, 01 Mar 2018 19:49:07 -0800 Dan Williams
wrote:
> When device-dax is operating in huge-page mode we want it to behave like
> hugetlbfs and report the MMU page mapping size that is being enforced by
> the vma. Similar to commit 31383c6865a5 "mm, hugetlbfs: introduce
> ->split() to vm_opera
Looks good,
Reviewed-by: Christoph Hellwig
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
> +static inline bool IS_DEVDAX(struct inode *inode)
> +{
> + if (!IS_ENABLED(CONFIG_DEV_DAX))
> + return false;
> + if ((inode->i_flags & S_DAX) == 0)
> + return false;
> + if (!S_ISCHR(inode->i_mode))
> + return false;
> + return true;
> +}
> +
On Thu, Mar 01, 2018 at 07:54:22PM -0800, Dan Williams wrote:
> static inline bool vma_is_dax(struct vm_area_struct *vma)
> {
> - return vma->vm_file && IS_DAX(vma->vm_file->f_mapping->host);
> + struct inode *inode;
> +
> + if (!vma->vm_file)
> + return false;
> + ino
On Fri, Mar 02, 2018 at 02:21:40PM -0800, Dan Williams wrote:
> They are indeed a hodge-podge. The problem is that the current
> IS_DAX() is broken. So I'd like to propose fixing IS_DAX() with
> IS_FSDAX() + IS_DEVDAX() for 4.16-rc4 and queue up these wider reworks
> you propose for the next merge
On Fri, Mar 2, 2018 at 2:57 PM, Christoph Hellwig wrote:
> On Fri, Mar 02, 2018 at 02:21:40PM -0800, Dan Williams wrote:
>> They are indeed a hodge-podge. The problem is that the current
>> IS_DAX() is broken. So I'd like to propose fixing IS_DAX() with
>> IS_FSDAX() + IS_DEVDAX() for 4.16-rc4 and
On Fri, Mar 2, 2018 at 3:49 PM, Dan Williams wrote:
> On Fri, Mar 2, 2018 at 2:57 PM, Christoph Hellwig wrote:
>> On Fri, Mar 02, 2018 at 02:21:40PM -0800, Dan Williams wrote:
>>> They are indeed a hodge-podge. The problem is that the current
>>> IS_DAX() is broken. So I'd like to propose fixing
27 matches
Mail list logo
