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
> + 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 firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/