On Wed, 16 Jun 2010 01:06:40 -0400 Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Wed, Jun 16, 2010 at 09:17:55AM +0900, KAMEZAWA Hiroyuki wrote: > > yes. It's only called from > > - page fault > > - add_to_page_cache() > > > > I think we'll see no stack problem. Now, memcg doesn't wakeup kswapd for > > reclaiming memory, it needs direct writeback. > > The page fault code should be fine, but add_to_page_cache can be called > with quite deep stacks. Two examples are grab_cache_page_write_begin > which already was part of one of the stack overflows mentioned in this > thread, or find_or_create_page which can be called via > _xfs_buf_lookup_pages, which can be called from under the whole XFS > allocator, or via grow_dev_page which might have a similarly deep > stack for users of the normal buffer cache. Although for the > find_or_create_page we usually should not have __GFP_FS set in the > gfp_mask. > Hmm. ok, then, memory cgroup needs some care. BTW, why xbf_buf_create() use GFP_KERNEL even if it can be blocked ? memory cgroup just limits pages for users, then, doesn't intend to limit kernel pages. If this buffer is not for user(visible page cache), but for internal structure, I'll have to add a code for ignoreing memory cgroup check when gfp_mask doesn't have GFP_MOVABLE. Thanks, -Kame -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>