linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Toshi Kani <toshi.kani@hpe.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>,
	Hugh Dickins <hughd@google.com>
Cc: akpm@linux-foundation.org, dan.j.williams@intel.com,
	viro@zeniv.linux.org.uk, willy@linux.intel.com,
	ross.zwisler@linux.intel.com, kirill.shutemov@linux.intel.com,
	david@fromorbit.com, jack@suse.cz, tytso@mit.edu,
	adilger.kernel@dilger.ca, mike.kravetz@oracle.com,
	linux-nvdimm@lists.01.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/2] thp, dax: add thp_get_unmapped_area for pmd mappings
Date: Mon, 25 Apr 2016 10:06:17 -0600	[thread overview]
Message-ID: <1461600377.8149.76.camel@hpe.com> (raw)
In-Reply-To: <20160424225057.GA6670@node.shutemov.name>

On Mon, 2016-04-25 at 01:50 +0300, Kirill A. Shutemov wrote:
> On Fri, Apr 22, 2016 at 06:21:22PM -0600, Toshi Kani wrote:
> > 
A :
> > +unsigned long __thp_get_unmapped_area(struct file *filp, unsigned long
> > len,
> > +		loff_t off, unsigned long flags, unsigned long size)
> > +{
> > +	unsigned long addr;
> > +	loff_t off_end = off + len;
> > +	loff_t off_align = round_up(off, size);
> > +	unsigned long len_pad;
> > +
> > +	if (off_end <= off_align || (off_end - off_align) < size)
> > +		return 0;
> > +
> > +	len_pad = len + size;
> > +	if (len_pad < len || (off + len_pad) < off)
> > +		return 0;
> > +
> > +	addr = current->mm->get_unmapped_area(filp, 0, len_pad,
> > +					A A A A A A off >> PAGE_SHIFT,
> > flags);
> > +	if (IS_ERR_VALUE(addr))
> > +		return 0;
> > +
> > +	addr += (off - addr) & (size - 1);
> > +	return addr;
>
> Hugh has more sanity checks before and after call to get_unmapped_area().
> Please, consider borrowing them.

This function only checks if the request is qualified for THP mappings. It
tries not to step into the implementation of the allocation code current-
>mm->get_unmapped_area(), such asA arch_get_unmapped_area_topdown() on x86.

Let me walk thru Hugh's checks to make sure I am not missing something:

---(Hugh's checks)---
| +	if (len > TASK_SIZE)
| +		return -ENOMEM;

This check is made by arch_get_unmapped_area_topdown().

| +
| +	get_area = current->mm->get_unmapped_area;
| +	addr = get_area(file, uaddr, len, pgoff, flags);
| +
| +	if (!IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE))
| +		return addr;

thp_get_unmapped_area() is defined to NULL in this case.

| +	if (IS_ERR_VALUE(addr))
| +		return addr;

Checked in my patch.

| +	if (addr & ~PAGE_MASK)
| +		return addr;

arch_get_unmapped_area_topdown() aligns 'addr' unless MAP_FIXED is set. No
need to check in this func.

| +	if (addr > TASK_SIZE - len)
| +		return addr;

The allocation code needs to assure this case.

| +	if (shmem_huge == SHMEM_HUGE_DENY)
| +		return addr;

This check is specific to Hugh's patch.

| +	if (len < HPAGE_PMD_SIZE)
| +		return addr;

Checked in my patch.

| +	if (flags & MAP_FIXED)
| +		return addr;

Checked by arch_get_unmapped_area_topdown().

| +	/*
| +	A * Our priority is to support MAP_SHARED mapped hugely;
| +	A * and support MAP_PRIVATE mapped hugely too, until it is COWed.
| +	A * But if caller specified an address hint, respect that as
before.
| +	A */
| +	if (uaddr)
| +		return addr;

Checked in my patch.

(cut)

| +	offset = (pgoff << PAGE_SHIFT) & (HPAGE_PMD_SIZE-1);
| +	if (offset && offset + len < 2 * HPAGE_PMD_SIZE)
| +		return addr;

Checked in my patch.

| +	if ((addr & (HPAGE_PMD_SIZE-1)) == offset)
| +		return addr;

This is a lucky case, i.e. the 1st get_unmapped_area() call returned an
aligned addr. Not applicable to my patch.

| +
| +	inflated_len = len + HPAGE_PMD_SIZE - PAGE_SIZE;
| +	if (inflated_len > TASK_SIZE)
| +		return addr;

Checked by arch_get_unmapped_area_topdown().

| +	if (inflated_len < len)
| +		return addr;

Checked in my patch.

| +	inflated_addr = get_area(NULL, 0, inflated_len, 0, flags);

Not sure why passing 'filp' and 'off' as NULL here.

| +	if (IS_ERR_VALUE(inflated_addr))
| +		return addr;

Checked in my patch.

| +	if (inflated_addr & ~PAGE_MASK)
| +		return addr;

Hmm... if this happens, it is a bug in the allocation code. I do not think
this check is necessary.

| +	inflated_offset = inflated_addr & (HPAGE_PMD_SIZE-1);
| +	inflated_addr += offset - inflated_offset;
| +	if (inflated_offset > offset)
| +		inflated_addr += HPAGE_PMD_SIZE;
| +
| +	if (inflated_addr > TASK_SIZE - len)
| +		return addr;

The allocation code needs to assure this.

| +	return inflated_addr;

> > 
> > +}
> > +
> > +unsigned long thp_get_unmapped_area(struct file *filp, unsigned long
> > addr,
> > +		unsigned long len, unsigned long pgoff, unsigned long
> > flags)
> > +{
> > +	loff_t off = (loff_t)pgoff << PAGE_SHIFT;
> > +
> > +	if (addr)
> > +		goto out;
>
> I think it's too strong reaction to hint, isn't it?
> We definately need this for MAP_FIXED. But in general? Maybe.

It calls arch's get_unmapped_area() to proceed with the original args when
'addr' is passed. The arch's get_unmapped_are() then handles 'addr' as a
hint when MAP_FIXED is not set. This can be used as a hint to avoid using
THP mappings if a non-aligned address is passed. Hugh's code handles it in
the same way as well.

Thanks,
-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>

  reply	other threads:[~2016-04-25 16:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-23  0:21 [PATCH v4 0/2] Align mmap address for DAX " Toshi Kani
2016-04-23  0:21 ` [PATCH v4 1/2] thp, dax: add thp_get_unmapped_area for " Toshi Kani
2016-04-24 22:50   ` Kirill A. Shutemov
2016-04-25 16:06     ` Toshi Kani [this message]
2016-04-23  0:21 ` [PATCH v4 2/2] ext2/4, xfs, blk: call thp_get_unmapped_area() " 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=1461600377.8149.76.camel@hpe.com \
    --to=toshi.kani@hpe.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=david@fromorbit.com \
    --cc=hughd@google.com \
    --cc=jack@suse.cz \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=mike.kravetz@oracle.com \
    --cc=ross.zwisler@linux.intel.com \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox