On Tue, 13 May 2014, Jianyu Zhan wrote:
> >> 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.
> >
> >But there are multiple p
>Preemption is mis-spelled throughout.
>
>Otherwise
>
>Reviewed-by: Christoph Lameter
Oops, corrected. Thanks.
-<8-
>From 1d0a080429542accfeac7de03e159a0bea12abba Mon Sep 17 00:00:00 2001
From: Jianyu Zhan
Date: Tue, 13 May 2014 00:19:08 +0800
Subject: [PATCH] mm: use the light version
On Tue, 13 May 2014, Jianyu Zhan wrote:
> diff --git a/mm/internal.h b/mm/internal.h
> index 07b6736..53d439e 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -196,7 +196,12 @@ static inline int mlocked_vma_newpage(struct
> vm_area_struct *vma,
> return 0;
>
> if (!Test
>> 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.
>
>But there are multiple pte locks for numerous page. Another process could
>
On Mon, 12 May 2014, Jianyu Zhan wrote:
> 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.
Ok. if these locations hold the pte loc
On Mon, 12 May 2014, Jianyu Zhan wrote:
> 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.
But there are multiple pte locks for nu
On Mon, May 12, 2014 at 10:01 PM, Christoph Lameter 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 m
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
>Your original __mod_zone_page_state happened to be correct;
>but you have no understanding of why it was correct, so its
>comment was very wrong, even after you changed the irq wording.
>
>This series just propagates your misunderstanding further,
>while providing an object lesson in how not to pr
On Sat, 10 May 2014, Jianyu Zhan wrote:
> __mod_zone_page_stat() is not irq-safe, so it should be used carefully.
> And it is not appropirately documented now. This patch adds comment for
> it, and also documents for some of its call sites.
>
> Suggested-by: Andrew Morton
> Signed-off-by: Jianyu
__mod_zone_page_stat() is not irq-safe, so it should be used carefully.
And it is not appropirately documented now. This patch adds comment for
it, and also documents for some of its call sites.
Suggested-by: Andrew Morton
Signed-off-by: Jianyu Zhan
---
mm/page_alloc.c | 2 ++
mm/rmap.c
11 matches
Mail list logo