On Thu, 12 Apr 2001, Jan Harkes wrote:
> But the VM pressure on the dcache and icache only comes into play once
> the system still has a free_shortage _after_ other attempts of freeing
> up memory in do_try_to_free_pages.
I don't think that it's necessary bad.
> sync_all_inodes, which is called from shrink_icache_memory is
> counterproductive at this point. Writing dirty inodes to disk,
> especially when there is a lot of them, requires additional page
> allocations.
Agreed, but that's
a) a separate story
b) not the case in situation mentioned above (all inodes are
busy).
> I have a patch that avoids unconditionally puts pressure on the dcache
> and icache, and avoids sync_all_inodes in shrink_icache_memory. An
> additional wakeup for the kupdate thread makes sure that inodes are more
> frequently written when there is no more free shortage. Maybe kupdated
> should be always get woken up.
Maybe, but I really doubt that constant pressure on dcache/icache is a
good idea. I'd rather see what will change from fixing that bug in
prune_dcache() before deciding what to do next.
> btw. Alexander, is the following a valid optimization to improve
> write-coalescing when calling sync_one for several inodes?
>
> inode.c:sync_one
>
> - filemap_fdatawait(inode->i_mapping);
> + if (sync) filemap_fdatawait(inode->i_mapping);
Umm... Probably.
-
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 : Sun Apr 15 2001 - 21:00:18 EST