On 2013/1/10 2:57, Tejun Heo wrote:
> Hello, Li.
>
> On Tue, Jan 08, 2013 at 09:31:11AM +0800, Li Zefan wrote:
>> I don't think Paul's still maintaining cpusets. Normally it's Andrew
>> that picks up cpuset patches. It's fine you route it through cgroup
>> tree.
>
> Can you please take over the
On 2013/1/10 2:57, Tejun Heo wrote:
Hello, Li.
On Tue, Jan 08, 2013 at 09:31:11AM +0800, Li Zefan wrote:
I don't think Paul's still maintaining cpusets. Normally it's Andrew
that picks up cpuset patches. It's fine you route it through cgroup
tree.
Can you please take over the cpuset
On Mon, Jan 7, 2013 at 5:31 PM, Li Zefan wrote:
>
> I don't think Paul's still maintaining cpusets. Normally it's Andrew
> that picks up cpuset patches. It's fine you route it through cgroup
> tree.
Yes, I'm sorry - I should have handed on cpusets at the time I had to
hand on cgroups. I was only
Hello, Li.
On Tue, Jan 08, 2013 at 09:31:11AM +0800, Li Zefan wrote:
> I don't think Paul's still maintaining cpusets. Normally it's Andrew
> that picks up cpuset patches. It's fine you route it through cgroup
> tree.
Can you please take over the cpuset maintainership then? I think you
would be
On 01/04/2013 01:35 AM, Tejun Heo wrote:
> Note that this leaves memcg as the only external user of cgroup_mutex.
> Michal, Kame, can you guys please convert memcg to use its own locking
> too?
I've already done this, I just have to rework it according to latest
feedback and repost it.
It should
On 01/04/2013 01:35 AM, Tejun Heo wrote:
Note that this leaves memcg as the only external user of cgroup_mutex.
Michal, Kame, can you guys please convert memcg to use its own locking
too?
I've already done this, I just have to rework it according to latest
feedback and repost it.
It should be
Hello, Li.
On Tue, Jan 08, 2013 at 09:31:11AM +0800, Li Zefan wrote:
I don't think Paul's still maintaining cpusets. Normally it's Andrew
that picks up cpuset patches. It's fine you route it through cgroup
tree.
Can you please take over the cpuset maintainership then? I think you
would be
On Mon, Jan 7, 2013 at 5:31 PM, Li Zefan lize...@huawei.com wrote:
I don't think Paul's still maintaining cpusets. Normally it's Andrew
that picks up cpuset patches. It's fine you route it through cgroup
tree.
Yes, I'm sorry - I should have handed on cpusets at the time I had to
hand on
On 2013/1/8 0:44, Tejun Heo wrote:
> Hello, Li.
>
> On Sun, Jan 06, 2013 at 04:27:00PM +0800, Li Zefan wrote:
>> I've reviewed and tested the patchset, and it looks good to me!
>>
>> Acked-by: Li Zefan
>
> Great. Ummm... How should we route this? Paul doesn't seem to be
> looking at this. I
Hello, Li.
On Sun, Jan 06, 2013 at 04:27:00PM +0800, Li Zefan wrote:
> I've reviewed and tested the patchset, and it looks good to me!
>
> Acked-by: Li Zefan
Great. Ummm... How should we route this? Paul doesn't seem to be
looking at this. I can route it through cgroup tree. Any
(2013/01/04 6:35), Tejun Heo wrote:
> Hello, guys.
>
> This is the second attempt at decoupling cpuset locking from cgroup
> core. Changes from the last take[L] are
>
> * cpuset-drop-async_rebuild_sched_domains.patch moved from 0007 to
>0009. This reordering makes cpu hotplug handling
(2013/01/04 6:35), Tejun Heo wrote:
Hello, guys.
This is the second attempt at decoupling cpuset locking from cgroup
core. Changes from the last take[L] are
* cpuset-drop-async_rebuild_sched_domains.patch moved from 0007 to
0009. This reordering makes cpu hotplug handling async first
Hello, Li.
On Sun, Jan 06, 2013 at 04:27:00PM +0800, Li Zefan wrote:
I've reviewed and tested the patchset, and it looks good to me!
Acked-by: Li Zefan lize...@huawei.com
Great. Ummm... How should we route this? Paul doesn't seem to be
looking at this. I can route it through cgroup tree.
On 2013/1/8 0:44, Tejun Heo wrote:
Hello, Li.
On Sun, Jan 06, 2013 at 04:27:00PM +0800, Li Zefan wrote:
I've reviewed and tested the patchset, and it looks good to me!
Acked-by: Li Zefan lize...@huawei.com
Great. Ummm... How should we route this? Paul doesn't seem to be
looking at
On 2013/1/4 5:35, Tejun Heo wrote:
> Hello, guys.
>
> This is the second attempt at decoupling cpuset locking from cgroup
> core. Changes from the last take[L] are
>
> * cpuset-drop-async_rebuild_sched_domains.patch moved from 0007 to
> 0009. This reordering makes cpu hotplug handling async
On 2013/1/4 5:35, Tejun Heo wrote:
Hello, guys.
This is the second attempt at decoupling cpuset locking from cgroup
core. Changes from the last take[L] are
* cpuset-drop-async_rebuild_sched_domains.patch moved from 0007 to
0009. This reordering makes cpu hotplug handling async first
Hello, guys.
This is the second attempt at decoupling cpuset locking from cgroup
core. Changes from the last take[L] are
* cpuset-drop-async_rebuild_sched_domains.patch moved from 0007 to
0009. This reordering makes cpu hotplug handling async first and
removes the temporary cyclic locking
Hello, guys.
This is the second attempt at decoupling cpuset locking from cgroup
core. Changes from the last take[L] are
* cpuset-drop-async_rebuild_sched_domains.patch moved from 0007 to
0009. This reordering makes cpu hotplug handling async first and
removes the temporary cyclic locking
18 matches
Mail list logo