Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757357AbZJ1FNv (ORCPT ); Wed, 28 Oct 2009 01:13:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757297AbZJ1FNu (ORCPT ); Wed, 28 Oct 2009 01:13:50 -0400 Received: from smtp-out.google.com ([216.239.33.17]:9558 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756621AbZJ1FNt (ORCPT ); Wed, 28 Oct 2009 01:13:49 -0400 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:user-agent:mime-version:content-type:x-system-of-record; b=FykVgM24yqxJfun+d+wA6sAXCRkVqEr18wUcyoIzT44CjBh9uJvw0ElWtLp7XUZmu qfqEO+LozA2B7DeGDf1+A== Date: Tue, 27 Oct 2009 22:13:44 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: KAMEZAWA Hiroyuki cc: vedran.furac@gmail.com, Hugh Dickins , linux-mm@kvack.org, linux-kernel@vger.kernel.org, KOSAKI Motohiro , minchan.kim@gmail.com, Andrew Morton , Andrea Arcangeli Subject: Re: Memory overcommit In-Reply-To: <20091028135519.805c4789.kamezawa.hiroyu@jp.fujitsu.com> Message-ID: References: <20091013120840.a844052d.kamezawa.hiroyu@jp.fujitsu.com> <20091014135119.e1baa07f.kamezawa.hiroyu@jp.fujitsu.com> <4ADE3121.6090407@gmail.com> <20091026105509.f08eb6a3.kamezawa.hiroyu@jp.fujitsu.com> <4AE5CB4E.4090504@gmail.com> <20091027122213.f3d582b2.kamezawa.hiroyu@jp.fujitsu.com> <4AE78B8F.9050201@gmail.com> <4AE792B8.5020806@gmail.com> <20091028135519.805c4789.kamezawa.hiroyu@jp.fujitsu.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1769 Lines: 48 On Wed, 28 Oct 2009, KAMEZAWA Hiroyuki wrote: > not related to child-parent problem. > > Seeing this number more. > == > [97137.709272] Active_anon:671487 active_file:82 inactive_anon:132316 > [97137.709273] inactive_file:82 unevictable:50 dirty:0 writeback:0 unstable:0 > [97137.709273] free:6122 slab:17179 mapped:30661 pagetables:8052 bounce:0 > == > > acitve_file + inactive_file is very low. Almost all pages are for anon. > But "mapped(NR_FILE_MAPPED)" is a little high. This implies remaining file caches > are mapped by many processes OR some mega bytes of shmem is used. > > # of pagetables is 8052, this means > 8052x4096/8*4k bytes = 16Gbytes of mapped area. > > Total available memory is near to be active/inactive + slab > 671487+82+132316+82+50+6122+17179+8052=835370x4k= 3.2Gbytes ? > (this system is swapless) > Yep: [97137.724965] 917504 pages RAM [97137.724967] 69721 pages reserved (917504 - 69721) * 4K = ~3.23G > Then, considering the pmap kosaki shows, > I guess killed ones had big total_vm but has not much real rss, > and no helps for oom. > echo 1 > /proc/sys/vm/oom_dump_tasks can confirm that. The bigger issue is making the distinction between killing a rogue task that is using much more memory than expected (the supposed current behavior, influenced from userspace by /proc/pid/oom_adj), and killing the task with the highest rss. The latter is definitely desired if we are allocating tons of memory but reduces the ability of the user to influence the badness score. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/