Re: [RFC] Limit the size of the pagecache

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

On Wed, 24 Jan 2007 18:41:27 -0800 (PST)
Christoph Lameter <clameter@sgi.com> 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/