All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Linux PPC dev <linuxppc-dev@ozlabs.org>,
	Hugh Dickins <hughd@google.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	kirill.shutemov@linux.intel.com
Subject: Re: Question on follow_page_mask
Date: Wed, 24 Feb 2016 16:52:30 +0530	[thread overview]
Message-ID: <56CD9276.9040105@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160223140349.GA21820@node.shutemov.name>

On 02/23/2016 07:33 PM, Kirill A. Shutemov wrote:
> On Tue, Feb 23, 2016 at 06:45:05PM +0530, Anshuman Khandual wrote:
>> Not able to understand the first code block of follow_page_mask
>> function. follow_huge_addr function is expected to find the page
>> struct for the given address if it turns out to be a HugeTLB page
>> but then when it finds the page we bug on if it had been called
>> with FOLL_GET flag.
>>
>> 	page = follow_huge_addr(mm, address, flags & FOLL_WRITE);
>> 	if (!IS_ERR(page)) {
>> 		BUG_ON(flags & FOLL_GET);
>> 		return page;
>> 	}
>>
>> do_move_page_to_node_array calls follow_page with FOLL_GET which
>> in turn calls follow_page_mask with FOLL_GET. On POWER, the
>> function follow_huge_addr is defined and does not return -EINVAL
>> like the generic one. It returns the page struct if its a HugeTLB
>> page. Just curious to know what is the purpose behind the BUG_ON.
> 
> I would guess requesting pin on non-reclaimable page is considered
> useless, meaning suspicius behavior. BUG_ON() is overkill, I think.
> WARN_ON_ONCE() would make it.

pin on non-reclaimable page ? I thought the page reference is obtained
for page migration purpose only. I may be missing something here.

> 
> Not that this follow_huge_addr() on Power is not reachable via
> do_move_page_to_node_array(), because the vma is !vma_is_migratable().

Was experimenting with that enabled via ARCH_ENABLE_HUGEPAGE_MIGRATION.

      parent reply	other threads:[~2016-02-24 11:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-23 13:15 Question on follow_page_mask Anshuman Khandual
2016-02-23 14:03 ` Kirill A. Shutemov
2016-02-23 21:07   ` Hugh Dickins
2016-02-24 11:45     ` Anshuman Khandual
2016-02-24 11:22   ` Anshuman Khandual [this message]

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=56CD9276.9040105@linux.vnet.ibm.com \
    --to=khandual@linux.vnet.ibm.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=hughd@google.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linuxppc-dev@ozlabs.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.