Re: [RFC][-mm] [0/7] misc memcg patch set

[Balbir Singh <balbir@linux.vnet.ibm.com>]

KAMEZAWA Hiroyuki wrote:
> Hi, it seems vmm-related bugs in -mm is reduced to some safe level.
> I restarted my patches for memcg.
> 
> This mail is just for dumping patches on my stack.
> (I'll resend one by one later.)
> 
> based on 2.6.26-rc5-mm3
> + kosaki's fixes + cgroup write_string set + Hugh Dickins's fixes for shmem
> (All patches are in -mm queue.)
> 
> Any comments are welcome (but 7/7 patch is not so neat...)
> 
> [1/7] swapcache handle fix for shmem.
> [2/7] adjust to split-lru: remove PAGE_CGROUP_FLAG_CACHE flag. 
> [3/7] adjust to split-lru: push shmem's page to active list
>       (Imported from Hugh Dickins's work.)
> [4/7] reduce usage at change limit. res_counter part.
> [5/7] reduce usage at change limit. memcg part.
> [6/7] memcg-background-job.           res_coutner part
> [7/7] memcg-background-job            memcg part.
> 
> Balbir, I'd like to import your idea of soft-limit to memcg-background-job
> patch set. (Maybe better than adding hooks to very generic part.)
> How do you think ?
> 

I am all for integration. My only requirement is that I want to reclaim from a
node when there is system memory contention. The soft limit patches touch the
generic infrastructure, just barely to indicate that we should look at
reclaiming from controllers over their soft limit.

> Other patches in plan (including other guy's)
> - soft-limit (Balbir works.)
>   I myself think memcg-background-job patches can copperative with this.
> 

That'll be nice thing to do. I am planning on a new version of the soft limit
patches soon (but due to data structure experimentation, it's taking me longer
to get done).

> - dirty_ratio for memcg. (haven't written at all)
>   Support dirty_ratio for memcg. This will improve OOM avoidance.
> 

OK, might be worth doing

> - swapiness for memcg (had patches..but have to rewrite.)
>   Support swapiness per memcg. (of no use ?)
> 

OK, Might be worth doing

> - swap_controller (Maybe Nishimura works on.)
>   The world may change after this...cgroup without swap can appears easily.
> 

I see a swap controller and swap namespace emerging, we'll need to see how they
work. The swap controller is definitely important

> - hierarchy (needs more discussion. maybe after OLS?)
>   have some pathes, but not in hurry.
> 

Same here, not in a hurry, but I think it will help define full functionality

> - more performance improvements (we need some trick.)
>   = Can we remove lock_page_cgroup() ?

We exchanged some early patches on this. We'll get back to it after the things
above.

>   = Can we reduce spinlocks ?
> 

Yes and most of our work happens under irqs disabled. We'll need to investigate
a bit more.

> - move resource at task move (needs helps from cgroup)
>   We need some magical way. It seems impossible to implement this only by memcg.
> 

I have some ideas on this. May be we can discuss this in the OLS BoF or on
email. This is low priority at the moment.

> - NUMA statistics (needs helps from cgroup)
>   It seems dynamic file creation feature or some rule to show array of
>   statistics should be defined.
> 
> - memory guarantee (soft-mlock.)
>   guard parameter against global LRU for saying "Don't reclaim from me more ;("
>   Maybe HA Linux people will want this....
> 

This is  hard goal to achieve, since we do have unreclaimable memory. Guarantees
would probably imply reservation of resources. Water marks might be a better way
to do it.

> Do you have others ?
> 

I think that should be it (it covers most if not all the documented TODOs we have)



-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>