From: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
To: 'Nick Piggin' <nickpiggin@yahoo.com.au>, Hugh Dickins <hugh@veritas.com>
Cc: 'David Gibson' <david@gibson.dropbear.id.au>,
g@ozlabs.org, Andrew Morton <akpm@osdl.org>,
'Christoph Lameter' <christoph@schroedinger.engr.sgi.com>,
bill.irwin@oracle.com, Adam Litke <agl@us.ibm.com>,
linux-mm@kvack.org
Subject: RE: [RFC] reduce hugetlb_instantiation_mutex usage
Date: Wed, 1 Nov 2006 02:17:28 -0800 [thread overview]
Message-ID: <000001c6fd9e$ef709230$8984030a@amr.corp.intel.com> (raw)
In-Reply-To: <45483C37.6040303@yahoo.com.au>
Nick Piggin wrote on Tuesday, October 31, 2006 10:19 PM
> So what does the normal page fault path do? Just invalidates the private
> page out of the page tables. A subsequent fault goes through the normal
> shared page path, which detects the truncation as it would with any
> shared fault. Right?
>
> hugetlb seems to pretty well follow the same pattern as memory.c in this
> regard. I don't see the race?
I was originally worried about a case that one thread fault on a private
mapping and get hold of a fresh page via alloc_huge_page(). While it executes
clear_huge_page(), 2nd thread come by did a ftruncate. After first thread
finish zeroing, I thought it will happily install a pte. But no, the inode
size check will prevent that from happening.
I was mislead by the comments in hugetlb_no_page() that page lock is used to
guard against racing truncation. Now I'm drifting back into what "racing
truncation" the comment is referring to. What race does it trying to protect
with page lock?
- Ken
--
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>
next prev parent reply other threads:[~2006-11-01 10:17 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-26 22:17 Chen, Kenneth W
2006-10-26 22:44 ` Andrew Morton
2006-10-26 23:31 ` 'David Gibson'
2006-10-27 0:04 ` Andrew Morton
2006-10-27 3:11 ` 'David Gibson'
2006-10-27 3:35 ` Andrew Morton
2006-10-27 4:06 ` 'David Gibson'
2006-10-31 2:54 ` Chen, Kenneth W
2006-10-31 3:17 ` 'David Gibson'
2006-10-31 5:15 ` Chen, Kenneth W
2006-10-31 11:05 ` 'David Gibson'
2006-10-31 12:48 ` Hugh Dickins
2006-11-01 6:18 ` Nick Piggin
2006-11-01 10:17 ` Chen, Kenneth W [this message]
2006-11-02 3:06 ` Nick Piggin
2006-11-02 2:29 ` 'David Gibson'
2006-10-27 1:47 ` 'David Gibson'
2006-10-30 20:55 ` Adam Litke
2006-10-26 23:47 ` 'David Gibson'
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='000001c6fd9e$ef709230$8984030a@amr.corp.intel.com' \
--to=kenneth.w.chen@intel.com \
--cc=agl@us.ibm.com \
--cc=akpm@osdl.org \
--cc=bill.irwin@oracle.com \
--cc=christoph@schroedinger.engr.sgi.com \
--cc=david@gibson.dropbear.id.au \
--cc=g@ozlabs.org \
--cc=hugh@veritas.com \
--cc=linux-mm@kvack.org \
--cc=nickpiggin@yahoo.com.au \
/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