From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 814FBC433DB for ; Fri, 29 Jan 2021 17:06:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5960664E03 for ; Fri, 29 Jan 2021 17:06:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231715AbhA2RG2 (ORCPT ); Fri, 29 Jan 2021 12:06:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46282 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229676AbhA2RGX (ORCPT ); Fri, 29 Jan 2021 12:06:23 -0500 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BBA1EC061573; Fri, 29 Jan 2021 09:05:42 -0800 (PST) Received: by mail-ej1-x62e.google.com with SMTP id ox12so14106703ejb.2; Fri, 29 Jan 2021 09:05:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sjU1ft3CFBesr8MYGZFVFpiy1HInqyD6mtninlntO/8=; b=UNyGZ0gKDZ5PJ0jlRi0rzX54uMKknI6+9o8e1gk8IhssVjwg+I8vBFqp9cJlxpLsQ7 Fn4t/zjEBE2eSb2hQStKvrS0377E8mqSxoYj6V8h/K474cqAQewOC7pb3SEVdgKcWDqa EAtyqtPJibedl0AeVa0vxdrYvQLClvm5ShiEThAywr7jQ25eQ2Q7Y+9Jhevd4nXQuLQo zKqk4vT1VOEIoXuQaGWcFj1UNdSFbKfB8lt83r6qj1QvYO1pKyYNJu8c1p+/UAnNWB4S 8a5djwz21voP7TEEZQt3wyEnD1ov2t/l0PlhobdWmuo2NzPok+WX3Mjyso5HeyF0cR3I N3Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sjU1ft3CFBesr8MYGZFVFpiy1HInqyD6mtninlntO/8=; b=T3Z7d6EC/lYCUUT3f8Cenau1GQOVG/G/pQJvqKfbIBTbAeEzGPCWUBj5zT1UAjLKWk TYfcyCwQMFFr5LOeZcwrDCcPGwFuBjLNQ+w08JCpt7qBVuA90Pe/yiBTxlBtEXZbw/5V LXXzJ+pWlIdVHW+LgpSsSMpS0NZUEw64wUnOtBoaOmHFBK/QLWzLrda68HgGyxtd6sdu m83QFmNRBrYK3yH+v6H12tYLCnr4M5aA+c9rdWlRj2LV0cWF/B9Kzdx4VmMcPUpF9uoQ 2YPcwojAWbeIBAD9INTxc2Hfe1rlbUWX4HsTpE5KJGJE+gkFjw+aQiRdpR7i5aqwKtGq o+OQ== X-Gm-Message-State: AOAM530H12BSBy/FeD8RsoxOp1oYHcjft4ZDObx0eU42EjD1s4DImifA y9ycGEq7PhPJiJq4BoZHk1EHHLAYagjMGFGYWM0= X-Google-Smtp-Source: ABdhPJyPXLfIMUhva87EtUR+iiGiROJdJ7Oao5cqEGU4srnfRxkHnMecVqPEQpyR0TV0+Ld6P+964XMnsC6dwXxtwpQ= X-Received: by 2002:a17:906:94d3:: with SMTP id d19mr5429345ejy.383.1611939941556; Fri, 29 Jan 2021 09:05:41 -0800 (PST) MIME-Version: 1.0 References: <20210127233345.339910-1-shy828301@gmail.com> <20210127233345.339910-5-shy828301@gmail.com> <255b9236-3e0b-f6f6-4a72-5e69351a979a@suse.cz> In-Reply-To: From: Yang Shi Date: Fri, 29 Jan 2021 09:05:30 -0800 Message-ID: Subject: Re: [v5 PATCH 04/11] mm: vmscan: remove memcg_shrinker_map_size To: Vlastimil Babka Cc: Roman Gushchin , Kirill Tkhai , Shakeel Butt , Dave Chinner , Johannes Weiner , Michal Hocko , Andrew Morton , Linux MM , Linux FS-devel Mailing List , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 29, 2021 at 3:22 AM Vlastimil Babka wrote: > > On 1/28/21 10:22 PM, Yang Shi wrote: > >> > @@ -266,12 +265,13 @@ int alloc_shrinker_maps(struct mem_cgroup *memcg) > >> > static int expand_shrinker_maps(int new_id) > >> > { > >> > int size, old_size, ret = 0; > >> > + int new_nr_max = new_id + 1; > >> > struct mem_cgroup *memcg; > >> > > >> > - size = DIV_ROUND_UP(new_id + 1, BITS_PER_LONG) * sizeof(unsigned long); > >> > - old_size = memcg_shrinker_map_size; > >> > + size = (new_nr_max / BITS_PER_LONG + 1) * sizeof(unsigned long); > >> > + old_size = (shrinker_nr_max / BITS_PER_LONG + 1) * sizeof(unsigned long); > >> > >> What's wrong with using DIV_ROUND_UP() here? > > > > I don't think there is anything wrong with DIV_ROUND_UP. Should be > > just different taste and result in shorter statement. > > IMHO it's not just taste. DIV_ROUND_UP() says what it does and you don't need to > guess it from the math expression. Also your expression is shorter as it simply > adds + 1, so if shrinker_nr_max is a multiple of BITS_PER_LONG, there's an extra > unsigned long that shouldn't be needed. People reading that code will wonder > whether there was some non-obvious intention behind that, and possibly send > cleanup patches. OK, will replace back to DIV_ROUND_UP(). And, a helper macro is introduced in patch #6, will add that helper in this patch and use DIV_ROUND_UP() in the helper. > > >> > >> > if (size <= old_size) > >> > - return 0; > >> > + goto out; > >> > >> Can this even happen? Seems to me it can't, so just remove this? > > > > Yes, it can. The maps use unsigned long value for bitmap, so any > > shrinker ID < 31 would fall into the same unsigned long, so we may see > > size <= old_size, but we need increase shrinker_nr_max since > > expand_shrinker_maps() is called iff id >= shrinker_nr_max. > > Ah, good point. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6FF61C433DB for ; Fri, 29 Jan 2021 17:05:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D936464E03 for ; Fri, 29 Jan 2021 17:05:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D936464E03 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EA6948D0003; Fri, 29 Jan 2021 12:05:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E55E28D0001; Fri, 29 Jan 2021 12:05:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D6C8A8D0003; Fri, 29 Jan 2021 12:05:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0075.hostedemail.com [216.40.44.75]) by kanga.kvack.org (Postfix) with ESMTP id C53448D0001 for ; Fri, 29 Jan 2021 12:05:44 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 7B3E4180ACF62 for ; Fri, 29 Jan 2021 17:05:44 +0000 (UTC) X-FDA: 77759439408.13.vest16_541820d275a9 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id 7DB7918140B7B for ; Fri, 29 Jan 2021 17:05:43 +0000 (UTC) X-HE-Tag: vest16_541820d275a9 X-Filterd-Recvd-Size: 5103 Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) by imf23.hostedemail.com (Postfix) with ESMTP for ; Fri, 29 Jan 2021 17:05:42 +0000 (UTC) Received: by mail-ej1-f45.google.com with SMTP id bl23so14071746ejb.5 for ; Fri, 29 Jan 2021 09:05:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sjU1ft3CFBesr8MYGZFVFpiy1HInqyD6mtninlntO/8=; b=UNyGZ0gKDZ5PJ0jlRi0rzX54uMKknI6+9o8e1gk8IhssVjwg+I8vBFqp9cJlxpLsQ7 Fn4t/zjEBE2eSb2hQStKvrS0377E8mqSxoYj6V8h/K474cqAQewOC7pb3SEVdgKcWDqa EAtyqtPJibedl0AeVa0vxdrYvQLClvm5ShiEThAywr7jQ25eQ2Q7Y+9Jhevd4nXQuLQo zKqk4vT1VOEIoXuQaGWcFj1UNdSFbKfB8lt83r6qj1QvYO1pKyYNJu8c1p+/UAnNWB4S 8a5djwz21voP7TEEZQt3wyEnD1ov2t/l0PlhobdWmuo2NzPok+WX3Mjyso5HeyF0cR3I N3Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sjU1ft3CFBesr8MYGZFVFpiy1HInqyD6mtninlntO/8=; b=D9W1EzTfIEliGQkNon6u4jWSUnlblN6QcBitj5R2TYdEcF63816116pEJSawzq/AL0 4f6in3BEBtgSdLDHaMfqPsPN0F55sHq4xyhSJVE1rsEWXQNjTiov5Y5L/T9jmlwHhaWl YJ7KSR4Be4F/Ow+38WwL8rQ5FS0zFwMUHXgJhIjhrChBcgs1NJ0l64oXozkyom6Ozstj wDryBDpx7x7hXQJgo32Rp5fSynB8kQDDFUU8MOnPEcnhXxQhVaRH7jsWLUSIhfNOLi19 pQkuY59B9SF0zXW5lNtBmh9dgjlMe2AkaZ6cuxe68eSWfrZ3XzJRSfrtFCgGCGeLMbr+ Vhcg== X-Gm-Message-State: AOAM5310MtziVte+KEjSdyKLaMoVrpB3/quPX/EDrLwy6rsCmHgvRmrC ztAh5DjywGpnpOdMJIAzFJNjtv6jdofW+z0ke14= X-Google-Smtp-Source: ABdhPJyPXLfIMUhva87EtUR+iiGiROJdJ7Oao5cqEGU4srnfRxkHnMecVqPEQpyR0TV0+Ld6P+964XMnsC6dwXxtwpQ= X-Received: by 2002:a17:906:94d3:: with SMTP id d19mr5429345ejy.383.1611939941556; Fri, 29 Jan 2021 09:05:41 -0800 (PST) MIME-Version: 1.0 References: <20210127233345.339910-1-shy828301@gmail.com> <20210127233345.339910-5-shy828301@gmail.com> <255b9236-3e0b-f6f6-4a72-5e69351a979a@suse.cz> In-Reply-To: From: Yang Shi Date: Fri, 29 Jan 2021 09:05:30 -0800 Message-ID: Subject: Re: [v5 PATCH 04/11] mm: vmscan: remove memcg_shrinker_map_size To: Vlastimil Babka Cc: Roman Gushchin , Kirill Tkhai , Shakeel Butt , Dave Chinner , Johannes Weiner , Michal Hocko , Andrew Morton , Linux MM , Linux FS-devel Mailing List , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Jan 29, 2021 at 3:22 AM Vlastimil Babka wrote: > > On 1/28/21 10:22 PM, Yang Shi wrote: > >> > @@ -266,12 +265,13 @@ int alloc_shrinker_maps(struct mem_cgroup *memcg) > >> > static int expand_shrinker_maps(int new_id) > >> > { > >> > int size, old_size, ret = 0; > >> > + int new_nr_max = new_id + 1; > >> > struct mem_cgroup *memcg; > >> > > >> > - size = DIV_ROUND_UP(new_id + 1, BITS_PER_LONG) * sizeof(unsigned long); > >> > - old_size = memcg_shrinker_map_size; > >> > + size = (new_nr_max / BITS_PER_LONG + 1) * sizeof(unsigned long); > >> > + old_size = (shrinker_nr_max / BITS_PER_LONG + 1) * sizeof(unsigned long); > >> > >> What's wrong with using DIV_ROUND_UP() here? > > > > I don't think there is anything wrong with DIV_ROUND_UP. Should be > > just different taste and result in shorter statement. > > IMHO it's not just taste. DIV_ROUND_UP() says what it does and you don't need to > guess it from the math expression. Also your expression is shorter as it simply > adds + 1, so if shrinker_nr_max is a multiple of BITS_PER_LONG, there's an extra > unsigned long that shouldn't be needed. People reading that code will wonder > whether there was some non-obvious intention behind that, and possibly send > cleanup patches. OK, will replace back to DIV_ROUND_UP(). And, a helper macro is introduced in patch #6, will add that helper in this patch and use DIV_ROUND_UP() in the helper. > > >> > >> > if (size <= old_size) > >> > - return 0; > >> > + goto out; > >> > >> Can this even happen? Seems to me it can't, so just remove this? > > > > Yes, it can. The maps use unsigned long value for bitmap, so any > > shrinker ID < 31 would fall into the same unsigned long, so we may see > > size <= old_size, but we need increase shrinker_nr_max since > > expand_shrinker_maps() is called iff id >= shrinker_nr_max. > > Ah, good point.