From: Hugh Dickins <hugh@veritas.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Rohit Seth <rohit.seth@intel.com>,
linux-kernel@vger.kernel.org, torvalds@osdl.org,
Adam Litke <agl@us.ibm.com>
Subject: Re: [PATCH]: Handling spurious page fault for hugetlb region for 2.6.14-rc4-git5
Date: Wed, 19 Oct 2005 16:48:01 +0100 (BST) [thread overview]
Message-ID: <Pine.LNX.4.61.0510191623220.7586@goblin.wat.veritas.com> (raw)
In-Reply-To: <20051018210721.4c80a292.akpm@osdl.org>
On Tue, 18 Oct 2005, Andrew Morton wrote:
> Rohit Seth <rohit.seth@intel.com> wrote:
> >
> > The prefetching problem is handled OK for regular pages because we can
> > handle page faults corresponding to those pages. That is currently not
> > true for hugepages. Currently the kernel assumes that PAGE_FAULT
> > happening against a hugetlb page is caused by truncate and returns
> > SIGBUS.
Is Rohit's intended to be a late 2.6.14 fix? We seem to have done well
without it for several years, and are just on the point of changing to
prefaulting the hugetlb pages anyway, which will fix it up.
> @@ -2045,8 +2045,18 @@ int __handle_mm_fault(struct mm_struct *
>
> inc_page_state(pgfault);
>
> - if (is_vm_hugetlb_page(vma))
> - return VM_FAULT_SIGBUS; /* mapping truncation does this. */
> + if (unlikely(is_vm_hugetlb_page(vma))) {
> + if (valid_hugetlb_file_off(vma, address))
> + /* We get here only if there was a stale(zero) TLB entry
> + * (because of HW prefetching).
> + * Low-level arch code (if needed) should have already
> + * purged the stale entry as part of this fault handling.
> + * Here we just return.
> + */
> + return VM_FAULT_MINOR;
> + else
> + return VM_FAULT_SIGBUS; /* mapping truncation does this. */
> + }
(I'm not surprised that the low-level arch code fixes this up as part of the
fault handling. I am surprised that it does so only after giving the fault
to the kernel. Sounds like something's gone wrong.)
What happens when the hugetlb file is truncated down and back up after
the mmap? Truncating down will remove a page from the mmap and flush TLB.
Truncating up will let accesses to the gone page pass the valid...off test.
But we've no support for hugetlb faulting in this version: so won't it get
get stuck in a tight loop?
If it's decided that this issue is actually an ia64 one, and does need to
be fixed right now, then I'd have thought your idea of fixing it at the
ia64 end better: arch/ia64/mm/fault.c already has code for discarding
faults on speculative loads, and ia64 has an RGN_HPAGE set aside for
hugetlb, so shouldn't it just discard speculative loads on that region?
Hugh
next prev parent reply other threads:[~2005-10-19 15:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-18 21:15 Seth, Rohit
2005-10-18 21:34 ` Andrew Morton
2005-10-18 22:17 ` Rohit Seth
2005-10-19 0:25 ` Andrew Morton
2005-10-19 3:25 ` Rohit Seth
2005-10-19 4:07 ` Andrew Morton
2005-10-19 14:33 ` Adam Litke
2005-10-19 15:48 ` Hugh Dickins [this message]
2005-10-19 19:05 ` Rohit Seth
2005-10-19 20:00 ` Hugh Dickins
2005-10-19 20:19 ` Andrew Morton
2005-10-19 20:28 ` Hugh Dickins
2005-10-19 23:53 ` Rohit Seth
2005-10-20 1:36 ` Rohit Seth
2005-10-20 1:37 ` Andrew Morton
2005-10-20 6:17 ` Hugh Dickins
2005-10-19 15:23 ` Hugh Dickins
2005-10-19 18:47 ` Rohit Seth
2005-10-19 20:53 ` Linus Torvalds
2005-10-19 21:59 ` Tony Luck
2005-10-20 0:05 ` Rohit Seth
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=Pine.LNX.4.61.0510191623220.7586@goblin.wat.veritas.com \
--to=hugh@veritas.com \
--cc=agl@us.ibm.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rohit.seth@intel.com \
--cc=torvalds@osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®