[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1405120858040.3090@gentwo.org>
Date: Mon, 12 May 2014 09:01:41 -0500 (CDT)
From: Christoph Lameter <cl@...ux.com>
To: Jianyu Zhan <nasa4836@...il.com>
cc: akpm@...ux-foundation.org, hughd@...gle.com, riel@...hat.com,
mgorman@...e.de, zhangyanfei@...fujitsu.com, aarcange@...hat.com,
fabf@...net.be, sasha.levin@...cle.com, oleg@...hat.com,
n-horiguchi@...jp.nec.com, iamjoonsoo.kim@....com,
kirill.shutemov@...ux.intel.com, gorcunov@...il.com,
dave.hansen@...ux.intel.com, toshi.kani@...com,
paul.gortmaker@...driver.com, srivatsa.bhat@...ux.vnet.ibm.com,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] mm: add comment for __mod_zone_page_stat
On Sun, 11 May 2014, Jianyu Zhan 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.
> > */
>
> Seconded. Christoph, would you please write a comment? I've written
> a new one based on Hugh's, would you please also take a look? Thanks.
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.
> It is essential to have such gurantees, because __mod_zone_page_stat()
> is a two-step operation : read-percpu-couter-then-modify-it.
> (Need comments. Christoph, do I misunderstand it?)
Yup.
> mlocked_vma_newpage() is only called in fault path by
> page_add_new_anon_rmap(), which is called on a *new* page.
> And such page is initially only visible via the pagetables, and the
> pte is locked while calling page_add_new_anon_rmap(), so we need not
> use an irq-safe mod_zone_page_state() here, using a light-weight version
> __mod_zone_page_state() would be OK.
This is wrong.. What you could say is that preemption is off and that the
counter is never incremented from an interrupt context that could race
with it. If this is the case then it would be safe.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists