From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757770Ab2DIWEL (ORCPT ); Mon, 9 Apr 2012 18:04:11 -0400 Received: from mail-iy0-f174.google.com ([209.85.210.174]:53039 "EHLO mail-iy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752633Ab2DIWEI (ORCPT ); Mon, 9 Apr 2012 18:04:08 -0400 Date: Mon, 9 Apr 2012 15:03:45 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: KOSAKI Motohiro cc: Konstantin Khlebnikov , Andrew Morton , linux-mm@kvack.org, KAMEZAWA Hiroyuki , linux-kernel@vger.kernel.org, Markus Trippelsdorf Subject: Re: [PATCH] mm: sync rss-counters at the end of exit_mm() In-Reply-To: Message-ID: References: <20120409200336.8368.63793.stgit@zurg> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323584-495961883-1334009032=:1859" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323584-495961883-1334009032=:1859 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 9 Apr 2012, KOSAKI Motohiro wrote: > On Mon, Apr 9, 2012 at 4:03 PM, Konstantin Khlebnikov > wrote: > > On task's exit do_exit() calls sync_mm_rss() but this is not enough, > > there can be page-faults after this point, for example exit_mm() -> > > mm_release() -> put_user() (for processing tsk->clear_child_tid). > > Thus there may be some rss-counters delta in current->rss_stat. >=20 > Seems reasonable. Yes, I think Konstantin has probably caught it; but I'd like to hear confirmation from Markus. > but I have another question. Do we have any reason to > keep sync_mm_rss() in do_exit()? I havn't seen any reason that thread exi= ting > makes rss consistency. IIRC it's all about the hiwater_rss/maxrss stuff: we want to sync the maximum rss into mm->hiwater_rss before it's transferred to signal->maxrss, and later made visible to the user though getrusage(RUSAGE_CHILDREN,) - does your reading confirm that? Konstantin now finds the child_tid and futex stuff can trigger faults raising rss beyond that point, but usually it won't go higher than when it was captured for maxrss there. The sync_mm_rss() added by this patch (after "tsk->mm =3D NULL" so *_mm_counter_fast() cannot store any more into the tsk even if there were more faults) is solely to satisfy Konstantin's check_mm(), and it is irritating to have that duplicated on the exit path. I'd be happy to see the new one put under CONFIG_DEBUG_VM along with check_mm(), once it's had a few -rcs of exposure without. Hugh >=20 >=20 > > > > Signed-off-by: Konstantin Khlebnikov > > Reported-by: Markus Trippelsdorf > > Cc: Hugh Dickins > > Cc: KAMEZAWA Hiroyuki > > --- > > =A0kernel/exit.c | =A0 =A01 + > > =A01 file changed, 1 insertion(+) > > > > diff --git a/kernel/exit.c b/kernel/exit.c > > index d8bd3b42..8e09dbe 100644 > > --- a/kernel/exit.c > > +++ b/kernel/exit.c > > @@ -683,6 +683,7 @@ static void exit_mm(struct task_struct * tsk) > > =A0 =A0 =A0 =A0enter_lazy_tlb(mm, current); > > =A0 =A0 =A0 =A0task_unlock(tsk); > > =A0 =A0 =A0 =A0mm_update_next_owner(mm); > > + =A0 =A0 =A0 sync_mm_rss(mm); > > =A0 =A0 =A0 =A0mmput(mm); > > =A0} > > --8323584-495961883-1334009032=:1859--