lkml.org 
[lkml]   [2012]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4/6] cgroups: forbid pre_destroy callback to fail
Hey, Michal.

On Thu, Oct 25, 2012 at 04:37:56PM +0200, Michal Hocko wrote:
> I am not sure I understand you here. So are you suggesting
> s/BUG_ON/WARN_ON_ONCE/ in this patch?

Oh, no, I meant that we can do upto patch 3 of this series and then
follow up with proper cgroup core update and then stack further
memcg cleanups on top.

> > Let's create a cgroup branch and build things there. I don't think
> > cgroup changes are gonna be a single patch and expect to see at least
> > some bug fixes afterwards and don't wanna keep them floating separate
> > from other cgroup changes.
>
> > mm being based on top of -next, that should work, right?
>
> Well, a tree based on -next is, ehm, impractical. I can create a bug on
> top of my -mm git branch (where I merge your cgroup common changes) for
> development and then when we are ready we can send it as a series and
> push it via Andrew. Would that work for you?
> Or we can push the core part via Andrew, wait for the merge and work on
> the follow up cleanups later?
> It is not like the follow up part is really urgent, isn't it? I would
> just like the memcg part settled first because this can potentially
> conflict with other memcg work.

Argh... can we pretty *please* just do a plain git branch? I don't
care where it is but I want to be able to pull it into cgroup core and
yes I do wanna make this happen in this devel cycle. We've been
sitting on it far too long waiting for memcg.

Thanks.

--
tejun


\
 
 \ /
  Last update: 2012-10-25 23:01    [W:0.094 / U:0.868 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site