lkml.org 
[lkml]   [2012]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/3] mm: adjust rss counters for migration entiries
KAMEZAWA Hiroyuki wrote:
> On Fri, 06 Jan 2012 21:38:56 +0400
> Konstantin Khlebnikov<khlebnikov@openvz.org> wrote:
>
>> Memory migration fill pte with migration entry and it didn't update rss counters.
>> Then it replace migration entry with new page (or old one if migration was failed).
>> But between this two passes this pte can be unmaped, or task can fork child and
>> it will get copy of this migration entry. Nobody account this into rss counters.
>>
>> This patch properly adjust rss counters for migration entries in zap_pte_range()
>> and copy_one_pte(). Thus we avoid extra atomic operations on migration fast-path.
>>
>> Signed-off-by: Konstantin Khlebnikov<khlebnikov@openvz.org>
>
> It's better to show wheter this is a bug-fix or not in changelog.
>
> IIUC, the bug-fix is the 1st harf of this patch + patch [2/3].
> Your new bug-check code is in patch[1/3] and 2nd half of this patch.
>

No, there only one new bug-check in 1st patch, this is non-fatal warning.
I didn't hide this check under CONFIG_VM_DEBUG because it rather small and
rss counters covers whole page-table management, this is very good invariant.
Currently I can trigger this warning only on this rare race -- extremely loaded
memory compaction catches this every several seconds.

1/3 bug-check
2/3 fix preparation
3/3 bugfix in two places:
do rss++ in copy_one_pte()
do rss-- in zap_pte_range()

> I think it's better to do bug-fix 1st and add bug-check later.
>
> So, could you reorder patches to bug-fix and new-bug-check ?

Patches didn't share any context, so they can be applied in any order.

>
> To the logic itself,
> Acked-by: KAMEZAWA Hiroyuki<kamezawa.hiroyu@jp.fujitsu.com>
> Please CC when you repost.
>
>
>




\
 
 \ /
  Last update: 2012-01-11 09:25    [from the cache]
©2003-2011 Jasper Spaans