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()?
-
-
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/
This archive was generated by hypermail 2b29 : Fri May 31 2002 - 22:00:12 EST