Re: inode highmem imbalance fix [Re: Bug with shared memory.]

[Andrew Morton <akpm@zip.com.au>]

Andrea Arcangeli wrote:
> 
> On Mon, May 20, 2002 at 06:30:40AM +0200, Andrea Arcangeli wrote:
> > As next thing I'll go ahead on the inode/highmem imbalance repored by
> > Alexey in the weekend.  Then the only pending thing before next -aa is
> 
> Here it is, you should apply it together with vm-35 that you need too
> for the bh/highmem balance (or on top of 2.4.19pre8aa3).

Looks OK to me.  But I wonder if it should be inside some config
option - I don't think machines with saner memory architectures
would want this?

> ...
> +                                        * in practice. Also keep in mind if somebody
> +                                        * keeps overwriting data in a flood we'd
> +                                        * never manage to drop the inode anyways,
> +                                        * and we really shouldn't do that because
> +                                        * it's an heavily used one.
> +                                        */

Can anyone actually write to an inode which is on the unused
list?

> +                                       wakeup_bdflush();
> +                               else if (inode->i_data.nrpages)
> +                                       /*
> +                                        * If we're here it means the only reason
> +                                        * we cannot drop the inode is that its
> +                                        * due its pagecache so go ahead and trim it
> +                                        * hard. If it doesn't go away it means
> +                                        * they're dirty or dirty/pinned pages ala
> +                                        * ramfs.
> +                                        *
> +                                        * invalidate_inode_pages() is a non
> +                                        * blocking operation but we introduce
> +                                        * a dependency order between the
> +                                        * inode_lock and the pagemap_lru_lock,
> +                                        * the inode_lock must always be taken
> +                                        * first from now on.
> +                                        */
> +                                       invalidate_inode_pages(inode);

It seems that a call to try_to_free_buffers() has snuck into
invalidate_inode_pages().  That means that clean ext3 pages
which are on the checkpoint list won't be released.  Could you
please change that to try_to_release_page()?


-