Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965236AbXAYDS5 (ORCPT ); Wed, 24 Jan 2007 22:18:57 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S965244AbXAYDS4 (ORCPT ); Wed, 24 Jan 2007 22:18:56 -0500 Received: from fgwmail5.fujitsu.co.jp ([192.51.44.35]:56430 "EHLO fgwmail5.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965236AbXAYDS4 (ORCPT ); Wed, 24 Jan 2007 22:18:56 -0500 Date: Thu, 25 Jan 2007 12:12:54 +0900 From: KAMEZAWA Hiroyuki To: Christoph Lameter Cc: aubreylee@gmail.com, svaidy@linux.vnet.ibm.com, nickpiggin@yahoo.com.au, rgetz@blackfin.uclinux.org, Michael.Hennerich@analog.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC] Limit the size of the pagecache Message-Id: <20070125121254.a2e91875.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: References: <20070124121318.6874f003.kamezawa.hiroyu@jp.fujitsu.com> <20070124141510.7775829c.kamezawa.hiroyu@jp.fujitsu.com> <20070125093259.74f76144.kamezawa.hiroyu@jp.fujitsu.com> Organization: Fujitsu X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.6.10; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2266 Lines: 61 On Wed, 24 Jan 2007 18:41:27 -0800 (PST) Christoph Lameter wrote: > > But I can't think of the way to show that. > > == > > [kamezawa@aworks src]$ free > > total used free shared buffers cached > > Mem: 741604 724628 16976 0 62700 564600 > > -/+ buffers/cache: 97328 644276 > > Swap: 1052216 2532 1049684 > > == > > Could we call the free memory "unused memory" and not talk about free > memory at all? > Ah, maybe it's better. I met several memory troubles in user's systems in these days. (on older kernels) Thousands/hundreds of process works on it. When I explain the cutomers about memory management, I devides memory into.. (1) unused memory --- memory which is not used, in free-list of zones. (2) reclaimable memory --- page cache, which is reclaimable clean pages --- can be reclaimed soon dirty pages --- need to be written back *BUT* busy pages are unreclaimable. (3) swappable memory --- user process's pages. basically reclaimable if swap is available. shmem pages are included here. (4) locked memory --- mlocked memory, which is not reclaimable(but movable) (5) kernel memory --- used by kernel, (and we can't see how many pages are reclaimable) We can know the amount of (1) and (5) and total memory. Basically, (3) = (Total) - (2) - (1). busy data-set of (2)(3) is not reclaimable. but the amount of busy data-set is unknown. Many users takes log of 'ps' or 'sar' to estimate their memory usage. (and sometimes page-cache of 'log-file' eats their memory.....) The amount of (4) is unknown. But there was a system with 6GB of 8GB memory was mlocked (--; and OOM works. I'm sorry that I can't catch up how the current kernel can show memory usage. I should investigate that. FYI: Because some customers are migrated from mainframes, they want to control almost all features in OS, IOW, designing memory usages. -Kame - 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/