linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: Hugh Dickins <hughd@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Hillf Danton <dhillf@gmail.com>,
	Russell King <linux@arm.linux.org.uk>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH] mm: hugetlb: flush dcache before returning zeroed huge page to userspace
Date: Tue, 7 Aug 2012 17:03:37 +0100	[thread overview]
Message-ID: <20120807160337.GC16877@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <20120712115708.GG21013@tiehlicka.suse.cz>

<resurrecting this thread>

On Thu, Jul 12, 2012 at 12:57:08PM +0100, Michal Hocko wrote:
> On Thu 12-07-12 12:26:45, Will Deacon wrote:
> > Well, the comment in linux/page-flags.h does state that:
> > 
> >  * PG_arch_1 is an architecture specific page state bit.  The generic code
> >  * guarantees that this bit is cleared for a page when it first is entered into
> >  * the page cache.
> > 
> > so it's not completely clear cut that the architecture should be responsible
> > for clearing this bit when allocating pages from the hugepage pool.
> 
> I think the wording is quite clear. It guarantees it gets cleared not
> clears it. So it is up to an arch specific functions called from the
> generic code to do that.

If we have to do this in arch-specific functions then:

	1. Where should we do it?
	2. Why don't we also do this for normal (non-huge) pages?

I looked at what happens for non-huge pages and the page flags are
cleared by *generic* code in free_pages_check:


  /*
   * Flags checked when a page is prepped for return by the page allocator.
   * Pages being prepped should not have any flags set.  It they are set,
   * there has been a kernel bug or struct page corruption.
   */
  #define PAGE_FLAGS_CHECK_AT_PREP	((1 << NR_PAGEFLAGS) - 1)

  static inline int free_pages_check(struct page *page)
  {
  	[...]
  	if (page->flags & PAGE_FLAGS_CHECK_AT_PREP)
  		page->flags &= ~PAGE_FLAGS_CHECK_AT_PREP;
  	return 0;
  }


Which guarantees to the arch-code that any new pages coming back from the
allocator will have PG_arch_1 clear. Why can't we just do something similar
for the hugepage pool?

Sorry to nag, but the discrepancy seems both unnecessary and unsolvable
at the arch level with the current hooks.

Will

--
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:[~2012-08-07 16:03 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-04 14:32 [PATCH] mm: hugetlb: flush dcache before returning zeroed huge page to userspace Will Deacon
2012-07-05 12:37 ` Hillf Danton
2012-07-05 14:17   ` Will Deacon
2012-07-06 13:15     ` Hillf Danton
2012-07-09 12:25 ` Michal Hocko
2012-07-09 14:13   ` Will Deacon
2012-07-09 23:57     ` Hugh Dickins
2012-07-10  9:45       ` Will Deacon
2012-07-10 10:42         ` Will Deacon
2012-07-11 17:48           ` Will Deacon
2012-07-12 11:16             ` Michal Hocko
2012-07-12 11:26               ` James Bottomley
2012-07-12 11:26               ` Will Deacon
2012-07-12 11:57                 ` Michal Hocko
2012-08-07 16:03                   ` Will Deacon [this message]
2012-08-08 16:26                     ` Michal Hocko
2012-08-16 16:09                       ` Will Deacon
2012-08-16 17:25                         ` Michal Hocko
2012-08-16 17:34                           ` Will Deacon
2012-08-16 18:06                             ` Michal Hocko
2012-08-16 18:19                               ` Will Deacon
2012-08-16 18:20                         ` Michal Hocko
2012-08-16 18:32                           ` Will Deacon

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=20120807160337.GC16877@mudshark.cambridge.arm.com \
    --to=will.deacon@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=dhillf@gmail.com \
    --cc=hughd@google.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mhocko@suse.cz \
    /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;
as well as URLs for NNTP newsgroup(s).