From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751392AbdBWKlV (ORCPT ); Thu, 23 Feb 2017 05:41:21 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:52278 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751156AbdBWKkU (ORCPT ); Thu, 23 Feb 2017 05:40:20 -0500 Subject: Re: [PATCH 2/2] mm/cgroup: delay soft limit data allocation To: Balbir Singh References: <1487779091-31381-1-git-send-email-ldufour@linux.vnet.ibm.com> <1487779091-31381-3-git-send-email-ldufour@linux.vnet.ibm.com> <20170223011644.GB8841@balbir.ozlabs.ibm.com> Cc: Johannes Weiner , Michal Hocko , Vladimir Davydov , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org From: Laurent Dufour Date: Thu, 23 Feb 2017 10:15:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170223011644.GB8841@balbir.ozlabs.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17022309-0008-0000-0000-000003EE7BB3 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17022309-0009-0000-0000-00001C909CA0 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-23_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702230091 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23/02/2017 02:16, Balbir Singh wrote: > On Wed, Feb 22, 2017 at 04:58:11PM +0100, Laurent Dufour wrote: >> Until a soft limit is set to a cgroup, the soft limit data are useless >> so delay this allocation when a limit is set. >> >> Suggested-by: Michal Hocko >> Signed-off-by: Laurent Dufour >> --- > >> @@ -3000,6 +3035,8 @@ static ssize_t mem_cgroup_write(struct kernfs_open_file *of, >> } >> break; >> case RES_SOFT_LIMIT: >> + if (!soft_limit_initialized) >> + soft_limit_initialize(); > > What happens if this fails? Do we disable this interface? > It's a good idea, but I wonder if we can deal with certain > memory cgroups not supporting soft limits due to memory > shortage at the time of using them. Thanks Balbir for the review. Regarding this point, Michal sent a new proposal which will return -ENOMEM in the case the initialization failed. I'll send a new series in that way. > >> memcg->soft_limit = nr_pages; >> ret = 0; >> break; > > Balbir Singh. >