Re: Bug with shared memory.

[Andrey Savochkin <saw@saw.sw.com.sg>]

Hi,

On Sun, May 19, 2002 at 10:21:18PM -0700, Andrew Morton wrote:
> Andrea Arcangeli wrote:
> > 
> > ...
> > As next thing I'll go ahead on the inode/highmem imbalance repored by
> > Alexey in the weekend.
> 
> (Some background:  the problem is that ZONE_NORMAL gets clogged with
>  inodes which are unfreeable because they have attached pagecache
>  pages.  There is no VM pressure against ZONE_HIGHMEM and there is
>  nothing which causes the pagecache pages to be freed.  The machine
>  dies due to ZONE_NORMAL exhaustion.  Workload is (presumably) the
>  reading or creation of a very large number of small files on a machine
>  which has much highmem.
> 
>  I expect Andrea is looking at a solution which releases pages against
>  unused inodes when there are many unused inodes, but prune_icache()
>  is failing to free sufficient inodes).
> 
> I'll be interested to see your solution ;)  We need to be careful to
> not over-shrink pagecache.  Also we need to be doubly-careful to
> ensure that LRU order is maintained on unused_list.
> 
> 
> I expect this is a compound bug: sure, ZONE_NORMAL is clogged with
> inodes.  But I bet it's also clogged with buffer_heads.  If the
> buffer_head problem was fixed then the inode problem would occur
> much later. - more highmem, more/smaller files.

In fact, running the test on different hardware, I saw both cases: just huge
inode cache and inodes+buffer_heads.

If ZONE_NORMAL is clogged with inodes+buffer_heads, the system works very
slowly (`tar x' on a test archive finishes in 20+ minutes instead of 20
seconds), but it's still alive.
If the test is aborted, the system returns to the normal state.

If ZONE_NORMAL is clogged with inodes only, the system looks completely frozen,
and only Magic-SysRq shows the attempts to shrink the cache.

	Andrey