Re: [RFC][PATCH 9/9 v2] memcg: never return error at pre_destroy()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Apr 27, 2012 at 5:25 PM, Hiroyuki Kamezawa
<kamezawa.hiroyuki@xxxxxxxxx> wrote:
> On Sat, Apr 28, 2012 at 6:28 AM, Ying Han <yinghan@xxxxxxxxxx> wrote:
>> On Thu, Apr 26, 2012 at 11:06 PM, KAMEZAWA Hiroyuki
>> <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
>>> When force_empty() called by ->pre_destroy(), no memory reclaim happens
>>> and it doesn't take very long time which requires signal_pending() check.
>>> And if we return -EINTR from pre_destroy(), cgroup.c show warning.
>>>
>>> This patch removes signal check in force_empty(). By this, ->pre_destroy()
>>> returns success always.
>>>
>>> Note: check for 'cgroup is empty' remains for force_empty interface.
>>>
>>> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx>
>>> ---
>>>  mm/hugetlb.c    |   10 +---------
>>>  mm/memcontrol.c |   14 +++++---------
>>>  2 files changed, 6 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>>> index 4dd6b39..770f1642 100644
>>> --- a/mm/hugetlb.c
>>> +++ b/mm/hugetlb.c
>>> @@ -1922,20 +1922,12 @@ int hugetlb_force_memcg_empty(struct cgroup *cgroup)
>>>        int ret = 0, idx = 0;
>>>
>>>        do {
>>> +               /* see memcontrol.c::mem_cgroup_force_empty() */
>>>                if (cgroup_task_count(cgroup)
>>>                        || !list_empty(&cgroup->children)) {
>>>                        ret = -EBUSY;
>>>                        goto out;
>>>                }
>>> -               /*
>>> -                * If the task doing the cgroup_rmdir got a signal
>>> -                * we don't really need to loop till the hugetlb resource
>>> -                * usage become zero.
>>> -                */
>>> -               if (signal_pending(current)) {
>>> -                       ret = -EINTR;
>>> -                       goto out;
>>> -               }
>>>                for_each_hstate(h) {
>>>                        spin_lock(&hugetlb_lock);
>>>                        list_for_each_entry(page, &h->hugepage_activelist, lru) {
>>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>>> index 2715223..ee350c5 100644
>>> --- a/mm/memcontrol.c
>>> +++ b/mm/memcontrol.c
>>> @@ -3852,8 +3852,6 @@ static int mem_cgroup_force_empty_list(struct mem_cgroup *memcg,
>>>                pc = lookup_page_cgroup(page);
>>>
>>>                ret = mem_cgroup_move_parent(page, pc, memcg, GFP_KERNEL);
>>> -               if (ret == -ENOMEM || ret == -EINTR)
>>> -                       break;
>>>
>>>                if (ret == -EBUSY || ret == -EINVAL) {
>>>                        /* found lock contention or "pc" is obsolete. */
>>> @@ -3863,7 +3861,7 @@ static int mem_cgroup_force_empty_list(struct mem_cgroup *memcg,
>>>                        busy = NULL;
>>>        }
>>>
>>> -       if (!ret && !list_empty(list))
>>> +       if (!loop)
>>
>> This looks a bit strange to me... why we make the change ?
>>
> Ah, I should this move to an independet patch.
> Because we don't have -ENOMEM path to exit loop, the return value of
> this function
> is
>  0 (if loop !=0 this means lru is empty under the lru lock )
>  -EBUSY (if loop== 0)

>
> I'll move this part out as an independent clean up patch

Thanks ~

--Ying

> thanks,
> -kame

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]