On Thu, 10 Jun 2010 02:10:35 +0100 Mel Gorman <mel@xxxxxxxxx> wrote: > > # mount -t cgroup none /cgroups -o memory > > # mkdir /cgroups/A > > # echo $$ > /cgroups/A > > # echo 300M > /cgroups/memory.limit_in_bytes > > # make -j 8 or make -j 16 > > > > That sort of scenario would be barely pushed by kernbench. For a single > kernel build, it's about 250-400M depending on the .config but it's still > a bit unreliable. Critically, it's not the sort of workload that would have > lots of long-lived mappings that would hurt a workload a lot if it was being > paged out. You're right. An excuse for me is that my concern is usually the amount of swap-out and OOM at rapid/heavy pressure comes because it's visible to users easily. So, I use short-lived process test. > Maybe it would be reasonable as a starting point but we'd have to be > very careful of the stack usage figures? I'm leaning towards this > approach to start with. > > I'm preparing another release that takes my two most important patches > about reclaim but also reduces usage in page relcaim (a combination of > two previously released series). In combination, it might be ok for the > memcg paths to reclaim pages from a stack perspective although the IO > pattern might still blow. sounds nice. > > > I'm not sure how a flusher thread would work just within a cgroup. It > > > would have to do a lot of searching to find the pages it needs > > > considering that it's looking at inodes rather than pages. > > > > > > > yes. So, I(we) need some way for coloring inode for selectable writeback. > > But people in this area are very nervous about performance (me too ;), I've > > not found the answer yet. > > > > I worry that too much targetting of writing back a specific inode would > have other consequences. I personally think this(writeback scheduling) is a job for I/O cgroup. So, I guess what memcg can do is dirty-ratio-limiting, at most. The user has to set well-balanced combination of memory+I/O cgroup. Sorry for wrong mixture of story. > > Okay, I'll consider about how to kick kswapd via memcg or flusher-for-memcg. > > Please go ahead as you want. I love good I/O pattern, too. > > > > For the moment, I'm strongly leaning towards allowing memcg to write > back pages. The IO pattern might not be great, but it would be in line > with current behaviour. The critical question is really "is it possible > to overflow the stack?". > Because I don't use XFS, I don't have relaiable answer, now. But, at least, memcg's memory reclaim will never be called as top of do_select(), which uses 1000 bytes. We have to consider long-term fix for I/O patterns under memmcg but please global-reclaim-update-first. We did in that way when splitting LRU to ANON and FILE. I don't want to make memcg as a burden for updating vmscan.c better. 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>