On Thu, 14 Jul 2011 11:07:00 -0400 Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Thu, Jul 14, 2011 at 01:46:34PM +0900, KAMEZAWA Hiroyuki wrote: > > > XFS and btrfs already disable writeback from memcg context, as does ext4 > > > for the typical non-overwrite workloads, and none has fallen apart. > > > > > > In fact there's no way we can enable them as the memcg calling contexts > > > tend to have massive stack usage. > > > > > > > Hmm, XFS/btrfs adds pages to radix-tree in deep stack ? > > We're using a fairly deep stack in normal buffered read/write, > wich is almost 100% common code. It's not just the long callchain > (see below), but also that we put the unneeded kiocb and a vector > of I/O vects on the stack: > > vfs_writev > do_readv_writev > do_sync_write > generic_file_aio_write > __generic_file_aio_write > generic_file_buffered_write > generic_perform_write > block_write_begin > grab_cache_page_write_begin > add_to_page_cache_lru > add_to_page_cache > add_to_page_cache_locked > mem_cgroup_cache_charge > > this might additionally come from in-kernel callers like nfsd, > which has even more stack space used. And at this point we only > enter the memcg/reclaim code, which last time I had a stack trace > ate up another about 3k of stack space. > Hmm. I'll prepare 2 functions for memcg 1. asynchronous memory reclaim as kswapd does. 2. dirty_ratio please remove ->writepage 1st. It may break memcg but it happens sometimes. We'll do fix. Thanks, -Kame _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
