Re: Bug with shared memory.

["Martin J. Bligh" <Martin.Bligh@us.ibm.com>]

> 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.

This should be easy to see from slabinfo. Note that the problem is
worse on a P4 - alignment takes us from 96 to 128 bytes.
 
> I've seen a vague report from the IBM team which indicates that 
> -aa VM does not solve the ZONE_NORMAL-full-of-buffer_heads lockup.  
> The workload was specweb on a 16 gig machine, I believe.

I haven't been very clear on this, mea culpa. We have two different
machines, each with 4 procs & 16Gb (at least). Both are exhausting
memory through buffer_heads. 

1) Running Oracle apps, doing raw IO. We are running an -aa kernel
on this machine, and it doesn't help. I believe that's just because
it's raw IO, though. We have some patches we did for TPC-H to fix
the raw IO problems with buffer_heads, and we'll be trying those
out this week.

2) Running specweb, doing non-raw IO. This is the machine we tried
Andrew's patch on and it worked a treat. We haven't tried the -aa
fix for this yet, I'll see if I can get that done this week.

So, we haven't really given Andrea's patch a fair test yet. If you
guys can agree which the better approach is by just discussing it,
great. If not, we'll benchmark the hell out of it, and decide things
that way ;-)

M