From: Matthew Wilcox <willy@linux.intel.com>
To: Toshi Kani <toshi.kani@hpe.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, 7 Apr 2016 13:41:11 -0400 [thread overview]
Message-ID: <20160407174111.GG2781@linux.intel.com> (raw)
In-Reply-To: <1459964672.20338.41.camel@hpe.com>
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.
> > 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.
_______________________________________________
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: Matthew Wilcox <willy@linux.intel.com>
To: Toshi Kani <toshi.kani@hpe.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, 7 Apr 2016 13:41:11 -0400 [thread overview]
Message-ID: <20160407174111.GG2781@linux.intel.com> (raw)
In-Reply-To: <1459964672.20338.41.camel@hpe.com>
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.
> > 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.
--
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: Matthew Wilcox <willy@linux.intel.com>
To: Toshi Kani <toshi.kani@hpe.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, 7 Apr 2016 13:41:11 -0400 [thread overview]
Message-ID: <20160407174111.GG2781@linux.intel.com> (raw)
In-Reply-To: <1459964672.20338.41.camel@hpe.com>
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.
> > 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.
next prev parent reply other threads:[~2016-04-07 17:41 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 [this message]
2016-04-07 17:41 ` Matthew Wilcox
2016-04-07 17:41 ` Matthew Wilcox
2016-04-07 21:20 ` Toshi Kani
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=20160407174111.GG2781@linux.intel.com \
--to=willy@linux.intel.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=toshi.kani@hpe.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.