On Wed, Apr 6, 2011 at 10:10 AM, Jan Kara <jack@xxxxxxx> wrote: > On Wed 06-04-11 12:08:05, Vivek Goyal wrote: >> On Wed, Apr 06, 2011 at 11:37:15AM -0400, Vivek Goyal wrote: >> >> [..] >> > > what kswapd is going to do writeback when the pages >> > > it's trying to writeback during a critical low memory event belong >> > > to a cgroup that is throttled at the IO level, etc. >> > >> > Throttling will move up so kswapd will not be throttled. Even today, >> > kswapd is part of root group and we do not suggest throttling root group. >> > >> > For the case of proportional disk sharing, we will probably account >> > IO to respective cgroups (pages submitted by kswapd) and that should >> > not flush to disk fairly fast and should not block for long time as it is >> > work consering mechanism. >> > >> > Do you see an issue with kswapd IO being accounted to respective cgroups >> > for proportional IO. For throttling case, all IO would go to root group >> > which is unthrottled and real issue of dirtying too many pages by >> > processes will be handled by throttling processes when they are dirtying >> > page cache. >> >> Or may be it is not a good idea to try to account pages to associated >> cgroups when memory is low and kswapd is doing IO. We can probably mark >> kswapd with some flag and account all IO to root group even for >> proportional weight mechanism. In this case isolation will be broken but >> I guess one can not do much. To avoid this situation, one should not >> have allowed too many writes and I think that's where low dirty ratio >> can come into the picture. > Well, I wouldn't bother too much with kswapd handling. MM people plan to > get rid of writeback from direct reclaim and just remove the dirty page > from LRU and recycle it once flusher thread writes it... But still, it matters which memcg is "responsible" for the background writeout from direct reclaim. One could argue that direct reclaim should just specify the root cgroup... Curt > > Honza > -- > Jan Kara <jack@xxxxxxx> > SUSE Labs, CR > -- > 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 > -- 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
