From: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
To: "'Zhang, Yanmin'" <yanmin_zhang@linux.intel.com>,
<linux-kernel@vger.kernel.org>
Cc: "David Gibson" <david@gibson.dropbear.id.au>
Subject: RE: [PATCH] hugetlb_no_page might break hugetlb quota
Date: Mon, 6 Mar 2006 00:15:33 -0800 [thread overview]
Message-ID: <200603060815.k268FXg07605@unix-os.sc.intel.com> (raw)
In-Reply-To: <1141626096.29825.13.camel@ymzhang-perf.sh.intel.com>
Zhang, Yanmin wrote on Sunday, March 05, 2006 10:22 PM
> In function hugetlb_no_page, backout path always calls hugetlb_put_quota.
> It's incorrect when find_lock_page gets the page or the new page is added
> into page cache.
While I acknowledge the bug, this patch is not complete. It makes file
system quota consistent with respect to page cache state. But such quota
(more severely, the page cache state) is still buggy, for example under
ftruncate case: if one ftrucate hugetlb file and then tries to fault a
page outside ftruncate area, a new hugetlb page is allocated and then
added into page cache along with file system quota; and at the end
returning VM_FAULT_SIGBUS. In this case, kernel traps an unreachable
page until possibly next mmap that extends it. That need to be fixed.
Which means we will be adding back conditional call to
hugetlb_put_quota(mapping) in the backout path.
> In addition, if the vma->vm_flags doesn't include VM_SHARED, the quota
> shouldn't be decreased.
Why? Private hugetlb page should be charged against the quota. Or is
there a better reason not to do so?
- Ken
next prev parent reply other threads:[~2006-03-06 8:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-06 6:21 [PATCH] hugetlb_no_page might break hugetlb quota Zhang, Yanmin
2006-03-06 8:15 ` Chen, Kenneth W [this message]
2006-03-06 9:06 ` Zhang, Yanmin
2006-03-08 3:14 ` Zhang, Yanmin
2006-03-08 3:24 ` [PATCH] ftruncate on huge page couldn't extend hugetlb file Zhang, Yanmin
[not found] ` <20060307222148.76e5dc45.akpm@osdl.org>
2006-03-08 6:54 ` Zhang, Yanmin
2006-03-08 18:28 ` Chen, Kenneth W
2006-03-08 23:58 ` David Gibson
2006-03-09 0:12 ` Chen, Kenneth W
2006-03-09 0:22 ` 'David Gibson'
2006-03-09 0:33 ` Chen, Kenneth W
2006-03-09 1:03 ` '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=200603060815.k268FXg07605@unix-os.sc.intel.com \
--to=kenneth.w.chen@intel.com \
--cc=david@gibson.dropbear.id.au \
--cc=linux-kernel@vger.kernel.org \
--cc=yanmin_zhang@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 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.