From: Toshi Kani <toshi.kani@hpe.com>
To: Matthew Wilcox <willy@linux.intel.com>
Cc: linux-nvdimm@lists.01.org, x86@kernel.org,
linux-kernel@vger.kernel.org, mingo@kernel.org,
linux-mm@kvack.org, hpa@zytor.com, tglx@linutronix.de,
bp@suse.de, kirill.shutemov@linux.intel.com
Subject: Re: [PATCH] x86 get_unmapped_area: Add PMD alignment for DAX PMD mmap
Date: Thu, 07 Apr 2016 15:20:33 -0600 [thread overview]
Message-ID: <1460064033.20338.74.camel@hpe.com> (raw)
In-Reply-To: <20160407174111.GG2781@linux.intel.com>
On Thu, 2016-04-07 at 13:41 -0400, Matthew Wilcox wrote:
> On Wed, Apr 06, 2016 at 11:44:32AM -0600, Toshi Kani wrote:
> > >
> > > The NVML chooses appropriate addresses and gets a properly aligned
> > > address without any kernel code.
> >
> > An application like NVML can continue to specify a specific address to
> > mmap(). Most existing applications, however, do not specify an address
> > to mmap(). With this patch, specifying an address will remain
> > optional.
>
> The point is that this *can* be done in userspace. You need to sell us
> on the advantages of doing it in the kernel.
Sure. As I said, the point is that we do not need to modify existing
applications for using DAX PMD mappings.
For instance, fio with "ioengine=mmap" performs I/Os with mmap().
https://github.com/caius/fio/blob/master/engines/mmap.c
With this change, unmodified fio can be used for testing with DAX PMD
mappings. There are many examples like this, and I do not think we want to
modify all applications that we want to evaluate/test with.
> > > I think this is the wrong place for it, if we decide that this is the
> > > right thing to do. The filesystem has a get_unmapped_area() which
> > > should be used instead.
> >
> > Yes, I considered adding a filesystem entry point, but decided going
> > this way because:
> > - arch_get_unmapped_area() and arch_get_unmapped_area_topdown() are
> > arch-specific code. Therefore, this filesystem entry point will need
> > arch-specific implementation.
> > - There is nothing filesystem specific about requesting PMD alignment.
>
> See http://article.gmane.org/gmane.linux.kernel.mm/149227 for Hugh's
> approach for shmem. I strongly believe that if we're going to do this
> i the kernel, we should build on this approach, and not hack something
> into each architecture's generic get_unmapped_area.
Thanks for the pointer. Yes, we can call current->mm->get_unmapped_area()
with size + PMD_SIZE, and adjust with the alignment in a filesystem entry
point. I will update the patch with this approach.
-Toshi
_______________________________________________
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: Toshi Kani <toshi.kani@hpe.com>
To: Matthew Wilcox <willy@linux.intel.com>
Cc: mingo@kernel.org, bp@suse.de, hpa@zytor.com, tglx@linutronix.de,
dan.j.williams@intel.com, kirill.shutemov@linux.intel.com,
linux-mm@kvack.org, x86@kernel.org, linux-nvdimm@lists.01.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86 get_unmapped_area: Add PMD alignment for DAX PMD mmap
Date: Thu, 07 Apr 2016 15:20:33 -0600 [thread overview]
Message-ID: <1460064033.20338.74.camel@hpe.com> (raw)
In-Reply-To: <20160407174111.GG2781@linux.intel.com>
On Thu, 2016-04-07 at 13:41 -0400, Matthew Wilcox wrote:
> On Wed, Apr 06, 2016 at 11:44:32AM -0600, Toshi Kani wrote:
> > >
> > > The NVML chooses appropriate addresses and gets a properly aligned
> > > address without any kernel code.
> >
> > An application like NVML can continue to specify a specific address to
> > mmap(). A Most existing applications, however, do not specify an address
> > to mmap(). A With this patch, specifying an address will remain
> > optional.
>
> The point is that this *can* be done in userspace.A A You need to sell us
> on the advantages of doing it in the kernel.
Sure. A As I said, the point is that we do not need to modify existing
applications for using DAX PMD mappings.
For instance, fio with "ioengine=mmap" performs I/Os with mmap().
https://github.com/caius/fio/blob/master/engines/mmap.c
With this change, unmodified fio can be used for testing with DAX PMD
mappings. A There are many examples like this, and I do not think we want to
modify all applications that we want to evaluate/test with.
> > > I think this is the wrong place for it, if we decide that this is the
> > > right thing to do.A A The filesystem has a get_unmapped_area() which
> > > should be used instead.
> >
> > Yes, I considered adding a filesystem entry point, but decided going
> > this way because:
> > A -A arch_get_unmapped_area() andA arch_get_unmapped_area_topdown() are
> > arch-specific code. A Therefore, this filesystem entry point will need
> > arch-specific implementation.A
> > A - There is nothing filesystem specific about requesting PMD alignment.
>
> See http://article.gmane.org/gmane.linux.kernel.mm/149227 for Hugh's
> approach for shmem.A A I strongly believe that if we're going to do this
> i the kernel, we should build on this approach, and not hack something
> into each architecture's generic get_unmapped_area.
Thanks for the pointer. A Yes, we can call current->mm->get_unmapped_area()
with size + PMD_SIZE, and adjust with the alignment in a filesystem entry
point. A I will update the patch with this approach.
-Toshi
--
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: Toshi Kani <toshi.kani@hpe.com>
To: Matthew Wilcox <willy@linux.intel.com>
Cc: mingo@kernel.org, bp@suse.de, hpa@zytor.com, tglx@linutronix.de,
dan.j.williams@intel.com, kirill.shutemov@linux.intel.com,
linux-mm@kvack.org, x86@kernel.org, linux-nvdimm@ml01.01.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86 get_unmapped_area: Add PMD alignment for DAX PMD mmap
Date: Thu, 07 Apr 2016 15:20:33 -0600 [thread overview]
Message-ID: <1460064033.20338.74.camel@hpe.com> (raw)
In-Reply-To: <20160407174111.GG2781@linux.intel.com>
On Thu, 2016-04-07 at 13:41 -0400, Matthew Wilcox wrote:
> On Wed, Apr 06, 2016 at 11:44:32AM -0600, Toshi Kani wrote:
> > >
> > > The NVML chooses appropriate addresses and gets a properly aligned
> > > address without any kernel code.
> >
> > An application like NVML can continue to specify a specific address to
> > mmap(). Most existing applications, however, do not specify an address
> > to mmap(). With this patch, specifying an address will remain
> > optional.
>
> The point is that this *can* be done in userspace. You need to sell us
> on the advantages of doing it in the kernel.
Sure. As I said, the point is that we do not need to modify existing
applications for using DAX PMD mappings.
For instance, fio with "ioengine=mmap" performs I/Os with mmap().
https://github.com/caius/fio/blob/master/engines/mmap.c
With this change, unmodified fio can be used for testing with DAX PMD
mappings. There are many examples like this, and I do not think we want to
modify all applications that we want to evaluate/test with.
> > > I think this is the wrong place for it, if we decide that this is the
> > > right thing to do. The filesystem has a get_unmapped_area() which
> > > should be used instead.
> >
> > Yes, I considered adding a filesystem entry point, but decided going
> > this way because:
> > - arch_get_unmapped_area() and arch_get_unmapped_area_topdown() are
> > arch-specific code. Therefore, this filesystem entry point will need
> > arch-specific implementation.
> > - There is nothing filesystem specific about requesting PMD alignment.
>
> See http://article.gmane.org/gmane.linux.kernel.mm/149227 for Hugh's
> approach for shmem. I strongly believe that if we're going to do this
> i the kernel, we should build on this approach, and not hack something
> into each architecture's generic get_unmapped_area.
Thanks for the pointer. Yes, we can call current->mm->get_unmapped_area()
with size + PMD_SIZE, and adjust with the alignment in a filesystem entry
point. I will update the patch with this approach.
-Toshi
next prev parent reply other threads:[~2016-04-07 21:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-06 13:58 [PATCH] x86 get_unmapped_area: Add PMD alignment for DAX PMD mmap Toshi Kani
2016-04-06 13:58 ` Toshi Kani
2016-04-06 13:58 ` Toshi Kani
2016-04-06 16:50 ` Matthew Wilcox
2016-04-06 16:50 ` Matthew Wilcox
2016-04-06 16:50 ` Matthew Wilcox
2016-04-06 17:44 ` Toshi Kani
2016-04-06 17:44 ` Toshi Kani
2016-04-06 17:44 ` Toshi Kani
2016-04-07 17:41 ` Matthew Wilcox
2016-04-07 17:41 ` Matthew Wilcox
2016-04-07 17:41 ` Matthew Wilcox
2016-04-07 21:20 ` Toshi Kani [this message]
2016-04-07 21:20 ` Toshi Kani
2016-04-07 21:20 ` Toshi Kani
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=1460064033.20338.74.camel@hpe.com \
--to=toshi.kani@hpe.com \
--cc=bp@suse.de \
--cc=hpa@zytor.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
--cc=willy@linux.intel.com \
--cc=x86@kernel.org \
/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.