From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yu Zhao Subject: Re: [PATCH v2] memcg: refactor mem_cgroup_resize_limit() Date: Sun, 4 Jun 2017 13:31:16 -0700 Message-ID: <20170604203116.GA19053@google.com> References: <20170601230212.30578-1-yuzhao@google.com> <20170604200437.17815-1-yuzhao@google.com> <20170604200942.GA23523@esperanza> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=5SZf+IdvpHizblnjKIjVMlcx87YLF+nb68GEL3nYbag=; b=LuN2TAyimWYF4xoC9kAFHbGJRLStodfcbEeQPOLhrRb+S+vjehigLUitUzQDAG0SqP cURpYw/eR64XXHyc4/YDZlRSIVWaARoTXGiFusLr0XxzDoCBpx1RFuM7ptYNJdLDM+Gi 8OG3i/mYYW/eBctEQGce7Uv7UIJrHQ4C4BMN2ssWIokONnPlCqLVPD7LOj/gBrgabj8B WPXPDJuLOO63R6tR0xGNKEE7L2PNS4ItYNPNe82xvcMBKNmxLd798eHJn4OLpnZR0VlV SJ5f6e5wYBa0UevAkcAXcOarAXMUpPyIesY2zXpM5LHWtYZ+9cdiJmVEdWdjrkvd5A/v T+5g== Content-Disposition: inline In-Reply-To: <20170604200942.GA23523@esperanza> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Vladimir Davydov Cc: Johannes Weiner , Michal Hocko , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, n.borisov.lkml-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org On Sun, Jun 04, 2017 at 11:09:42PM +0300, Vladimir Davydov wrote: > On Sun, Jun 04, 2017 at 01:04:37PM -0700, Yu Zhao wrote: > > @@ -2498,22 +2449,24 @@ static int mem_cgroup_resize_memsw_limit(struct mem_cgroup *memcg, > > } > > > > mutex_lock(&memcg_limit_mutex); > > - if (limit < memcg->memory.limit) { > > + inverted = memsw ? limit < memcg->memory.limit : > > + limit > memcg->memsw.limit; > > + if (inverted) > > mutex_unlock(&memcg_limit_mutex); > > ret = -EINVAL; > > break; > > } > > For some reason, I liked this patch more without this extra variable :-) Well, I'll refrain myself from commenting more because we are now at the risk of starting a coding style war over this. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f71.google.com (mail-pg0-f71.google.com [74.125.83.71]) by kanga.kvack.org (Postfix) with ESMTP id A7F356B0292 for ; Sun, 4 Jun 2017 16:31:21 -0400 (EDT) Received: by mail-pg0-f71.google.com with SMTP id 8so56779410pgc.12 for ; Sun, 04 Jun 2017 13:31:21 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com. [2607:f8b0:400e:c00::22d]) by mx.google.com with ESMTPS id q12si6301426pgr.237.2017.06.04.13.31.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jun 2017 13:31:20 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id n23so73539717pfb.2 for ; Sun, 04 Jun 2017 13:31:20 -0700 (PDT) Date: Sun, 4 Jun 2017 13:31:16 -0700 From: Yu Zhao Subject: Re: [PATCH v2] memcg: refactor mem_cgroup_resize_limit() Message-ID: <20170604203116.GA19053@google.com> References: <20170601230212.30578-1-yuzhao@google.com> <20170604200437.17815-1-yuzhao@google.com> <20170604200942.GA23523@esperanza> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170604200942.GA23523@esperanza> Sender: owner-linux-mm@kvack.org List-ID: To: Vladimir Davydov Cc: Johannes Weiner , Michal Hocko , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, n.borisov.lkml@gmail.com On Sun, Jun 04, 2017 at 11:09:42PM +0300, Vladimir Davydov wrote: > On Sun, Jun 04, 2017 at 01:04:37PM -0700, Yu Zhao wrote: > > @@ -2498,22 +2449,24 @@ static int mem_cgroup_resize_memsw_limit(struct mem_cgroup *memcg, > > } > > > > mutex_lock(&memcg_limit_mutex); > > - if (limit < memcg->memory.limit) { > > + inverted = memsw ? limit < memcg->memory.limit : > > + limit > memcg->memsw.limit; > > + if (inverted) > > mutex_unlock(&memcg_limit_mutex); > > ret = -EINVAL; > > break; > > } > > For some reason, I liked this patch more without this extra variable :-) Well, I'll refrain myself from commenting more because we are now at the risk of starting a coding style war over this. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751327AbdFDUb0 (ORCPT ); Sun, 4 Jun 2017 16:31:26 -0400 Received: from mail-pf0-f180.google.com ([209.85.192.180]:35355 "EHLO mail-pf0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751197AbdFDUbV (ORCPT ); Sun, 4 Jun 2017 16:31:21 -0400 Date: Sun, 4 Jun 2017 13:31:16 -0700 From: Yu Zhao To: Vladimir Davydov Cc: Johannes Weiner , Michal Hocko , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, n.borisov.lkml@gmail.com Subject: Re: [PATCH v2] memcg: refactor mem_cgroup_resize_limit() Message-ID: <20170604203116.GA19053@google.com> References: <20170601230212.30578-1-yuzhao@google.com> <20170604200437.17815-1-yuzhao@google.com> <20170604200942.GA23523@esperanza> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170604200942.GA23523@esperanza> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jun 04, 2017 at 11:09:42PM +0300, Vladimir Davydov wrote: > On Sun, Jun 04, 2017 at 01:04:37PM -0700, Yu Zhao wrote: > > @@ -2498,22 +2449,24 @@ static int mem_cgroup_resize_memsw_limit(struct mem_cgroup *memcg, > > } > > > > mutex_lock(&memcg_limit_mutex); > > - if (limit < memcg->memory.limit) { > > + inverted = memsw ? limit < memcg->memory.limit : > > + limit > memcg->memsw.limit; > > + if (inverted) > > mutex_unlock(&memcg_limit_mutex); > > ret = -EINVAL; > > break; > > } > > For some reason, I liked this patch more without this extra variable :-) Well, I'll refrain myself from commenting more because we are now at the risk of starting a coding style war over this.