On Tue, 15 Jun 2010 15:16:01 +0100 Mel Gorman <mel@xxxxxxxxx> wrote: > On Tue, Jun 15, 2010 at 10:04:24AM -0400, Rik van Riel wrote: > > On 06/15/2010 09:59 AM, Mel Gorman wrote: > >> On Tue, Jun 15, 2010 at 09:34:18AM -0400, Rik van Riel wrote: > >>> On 06/15/2010 07:45 AM, Mel Gorman wrote: > > > >>>>>> > >>>>>> +/* kswapd and memcg can writeback as they are unlikely to overflow stack */ > >>>>>> +static inline bool reclaim_can_writeback(struct scan_control *sc) > >>>>>> +{ > >>>>>> + return current_is_kswapd() || sc->mem_cgroup != NULL; > >>>>>> +} > > > >>> If direct reclaim can overflow the stack, so can direct > >>> memcg reclaim. That means this patch does not solve the > >>> stack overflow, while admitting that we do need the > >>> ability to get specific pages flushed to disk from the > >>> pageout code. > >>> > >> > >> What path is taken with memcg != NULL that could overflow the stack? I > >> couldn't spot one but mm/memcontrol.c is a bit tangled so finding all > >> its use cases is tricky. The critical path I had in mind though was > >> direct reclaim and for that path, memcg == NULL or did I miss something? > > > > mem_cgroup_hierarchical_reclaim -> try_to_free_mem_cgroup_pages > > > > But in turn, where is mem_cgroup_hierarchical_reclaim called from direct > reclaim? It appears to be only called from the fault path or as a result > of the memcg changing size. > 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. Thanks, -Kame -- 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