Messages in this thread | | | Date | Fri, 24 May 2002 01:04:35 -0700 | From | Andrew Morton <> | Subject | Re: inode highmem imbalance fix [Re: Bug with shared memory.] |
| |
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/
| |