From: Jianyu Zhan <nasa4836@gmail.com>
To: Christoph Lameter <cl@linux.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Hugh Dickins <hughd@google.com>, Rik van Riel <riel@redhat.com>,
Mel Gorman <mgorman@suse.de>,
Zhang Yanfei <zhangyanfei@cn.fujitsu.com>,
Andrea Arcangeli <aarcange@redhat.com>,
fabf@skynet.be, sasha.levin@oracle.com, oleg@redhat.com,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
iamjoonsoo.kim@lge.com, kirill.shutemov@linux.intel.com,
Cyrill Gorcunov <gorcunov@gmail.com>,
dave.hansen@linux.intel.com, toshi.kani@hp.com,
paul.gortmaker@windriver.com, srivatsa.bhat@linux.vnet.ibm.com,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] mm: add comment for __mod_zone_page_stat
Date: Mon, 12 May 2014 23:19:55 +0800 [thread overview]
Message-ID: <CAHz2CGUfLx7DNgdNoAL0G3a9Ht6yf3bhWaojjNx91aF7L-iDQw@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1405120858040.3090@gentwo.org>
On Mon, May 12, 2014 at 10:01 PM, Christoph Lameter <cl@linux.com> wrote:
> >
> >/*
> > * For use when we know that interrupts are disabled,
> > * or when we know that preemption is disabled and that
> > * particular counter cannot be updated from interrupt context.
> > */
>
> The description above looks ok to me. The problem is that you are
> considering the page related data structures as an issue for races and not
> the data structures relevant for vm statistics.
Hi, Christoph,
Yep. I did.
Let me restate the point here.
To use __mod_zone_page_stat when we know that either
1. interrupts are disabled, or
2. preemption is disabled and that particular counter cannot be
updated from interrupt context.
For those call sites currently using __mod_zone_page_stat, they just guarantees
the counter is never modified from an interrupt context, but doesn't disable
preemption.
This means they guarantee that even they are preemted the vm
counter won't be modified incorrectly. Because the counter is page-related
(e.g., a new anon page added), and they are exclusively hold the pte lock.
This is why I emphasized on 'the page related data structures as an
issue for races'.
So, as you concludes in the other mail that __modd_zone_page_stat
couldn't be used.
in mlocked_vma_newpage, then what qualifies other call sites for using
it, in the same situation?
See:
void page_add_new_anon_rmap(struct page *page,
struct vm_area_struct *vma, unsigned long address)
{
VM_BUG_ON(address < vma->vm_start || address >= vma->vm_end);
SetPageSwapBacked(page);
atomic_set(&page->_mapcount, 0); /* increment count (starts at -1) */
if (PageTransHuge(page))
__inc_zone_page_state(page, NR_ANON_TRANSPARENT_HUGEPAGES);
__mod_zone_page_state(page_zone(page), NR_ANON_PAGES,
hpage_nr_pages(page)); <--- using it.
__page_set_anon_rmap(page, vma, address, 1);
if (!mlocked_vma_newpage(vma, page)) { <--- couldn't use it ?
SetPageActive(page);
lru_cache_add(page);
} else
add_page_to_unevictable_list(page);
}
Hope I express it clearly enough. Thanks.
--
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:[~2014-05-12 15:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-11 12:31 Jianyu Zhan
2014-05-12 14:01 ` Christoph Lameter
2014-05-12 15:19 ` Jianyu Zhan [this message]
2014-05-12 16:05 ` Christoph Lameter
2014-05-12 16:07 ` Christoph Lameter
-- strict thread matches above, loose matches on Subject: below --
2014-05-12 17:36 Jianyu Zhan
2014-05-12 16:33 Jianyu Zhan
2014-05-12 16:57 ` Christoph Lameter
2014-05-14 3:59 ` Hugh Dickins
2014-05-10 7:15 Jianyu Zhan
2014-05-10 19:51 ` Hugh Dickins
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=CAHz2CGUfLx7DNgdNoAL0G3a9Ht6yf3bhWaojjNx91aF7L-iDQw@mail.gmail.com \
--to=nasa4836@gmail.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=dave.hansen@linux.intel.com \
--cc=fabf@skynet.be \
--cc=gorcunov@gmail.com \
--cc=hughd@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=oleg@redhat.com \
--cc=paul.gortmaker@windriver.com \
--cc=riel@redhat.com \
--cc=sasha.levin@oracle.com \
--cc=srivatsa.bhat@linux.vnet.ibm.com \
--cc=toshi.kani@hp.com \
--cc=zhangyanfei@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox