On Wed, May 21, 2008 at 02:25:05AM +0400, Evgeniy Polyakov (johnpol@xxxxxxxxxxx) wrote:
> > Oh, god no. Let's not put the inode_lock right at the top of
> > the VM page cleaning path. We don't need to modify inode state,
> > the superblock dirty lists, etc - all we need to do is write
> > dirty pages on a given mapping in a more efficient manner.
>
> I'm not advocating that, but having swap on reclaim does not hurt
> anyone, this is essentially the same, but with different underlying
> storage. System will do that anyway sooner or later during usual
> writeback, which in turn can be a result of the same reclaim...
And actually having tiny operations under inode_lock is the last thing
to worry about when we are about to start writing pages to disk because
memory is so fragmented that we need to move things around.
That is the simplest from the typing viewpoint, one can also do
something like that:
struct address_space *mapping = page->mapping;
struct backing_dev_info *bdi = mapping->backing_dev_info;
struct writeback_control wbc = {
.bdi = bdi,
.sync_mode = WB_SYNC_ALL, /* likly we want to wait... */
.older_than_this = NULL,
.nr_to_write = 13,
.range_cyclic = 0,
.range_start = start_index,
.range_end = end_index
};
do_writepages(mapping, &wbc);
Cristoph, is this example you wnated to check out? It will only try to
write .nr_to_write pages between .range_start and .range_end without
syncing inode info itself.
--
Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
