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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 504C1C433EF for ; Wed, 13 Oct 2021 23:45:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C5BBC610CE for ; Wed, 13 Oct 2021 23:45:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C5BBC610CE Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 18C42900002; Wed, 13 Oct 2021 19:45:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 116426B0071; Wed, 13 Oct 2021 19:45:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF87F900002; Wed, 13 Oct 2021 19:45:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0089.hostedemail.com [216.40.44.89]) by kanga.kvack.org (Postfix) with ESMTP id DA6B16B006C for ; Wed, 13 Oct 2021 19:45:49 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 7BA608249980 for ; Wed, 13 Oct 2021 23:45:49 +0000 (UTC) X-FDA: 78693049218.27.B85F0B8 Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by imf15.hostedemail.com (Postfix) with ESMTP id AFFD2D00009A for ; Wed, 13 Oct 2021 23:45:48 +0000 (UTC) Received: by mail-lf1-f47.google.com with SMTP id r19so18590468lfe.10 for ; Wed, 13 Oct 2021 16:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MIPgO8yQiZn6tL7PQw0ynB/vmiHfdbnsw7Yxik4Gs5c=; b=Zo/oxYeUHUiu5epy5RMTUChC69BfvR/wzXIz5N5eUMfhimDPUDYzklPhtmFozV4kR2 nql9Z92aM87i6pjK6Xmv7cDjU1nKQ8VNvISZjUcdFcl7sX54/5sivvQJF0112hHD5cAu 6FSMFfQxpW8Bhe8w72Ns8DjQaO2vBG6jBTMjYQV4l81pQMst03i4Drd2f9IF2na682+u HpGrHoNfUa0Gg0sRUqFJbuOs+PoVDiErmce946h8Kc/RfXxI9lviBiTCLqjrAlsVcFt2 tYwVoR5zv7LJqtTFU0rkKAiE4bscZAQWKs3CO77dpKj2PYCI1awVeJ1tAWTq6ZcVwPKh tq8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MIPgO8yQiZn6tL7PQw0ynB/vmiHfdbnsw7Yxik4Gs5c=; b=OB9alrjGLgfsvH9+5tmdqyHCQ+XY9dn+Bou7T+gYSpN/fpkqYnb/O906pyvY7C9R7s hvB8hQ6E5PQ72X2aPbjo1FgW2Xn9vvanYnkqlxWPVMFJZh74+FAdVhtZuHiIRtnp45NB N/ggZKvpSF1+QSZzn6PWealJXLWwMPOMsMy5TkzujuM4ZPsbFPU7yoVobtYPpPjc039j ju0ECUszUdODdBj9SUY/dbLQUG3Hm/ZCjgma3HBmoKiTGhs/ynwSgWhKkvUVmnGUAr5b LEIZ6zwbZm9yvSZSDLy6L8B1+a68FfakZEFIzRrQRoREK73QaOM8GEa0Cvg32tkKcJnJ 3VJw== X-Gm-Message-State: AOAM530gtPOPUmq5XTYVfmkVhB0DSCo7RWuHL120bkdrB5b6ysuNyoOl K4G2H3WExvjGHzrm/i1qw7vikQLOkSq3AUmcAoU0WA== X-Google-Smtp-Source: ABdhPJyDl1zBaewozzQDXu7rBd1rwYDCVVOiWOdbVlTGe18dat8YOQKe98Nhwh+PQ2I1FOPDIsFZfw1RoMqyaWqm+x0= X-Received: by 2002:a05:6512:131b:: with SMTP id x27mr1851832lfu.210.1634168747346; Wed, 13 Oct 2021 16:45:47 -0700 (PDT) MIME-Version: 1.0 References: <20211013194338.1804247-1-shakeelb@google.com> In-Reply-To: From: Shakeel Butt Date: Wed, 13 Oct 2021 16:45:35 -0700 Message-ID: Subject: Re: [PATCH] memcg: page_alloc: skip bulk allocator for __GFP_ACCOUNT To: Roman Gushchin Cc: Johannes Weiner , Michal Hocko , Mel Gorman , Uladzislau Rezki , Vasily Averin , Andrew Morton , Cgroups , Linux MM , LKML Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="Zo/oxYeU"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf15.hostedemail.com: domain of shakeelb@google.com designates 209.85.167.47 as permitted sender) smtp.mailfrom=shakeelb@google.com X-Stat-Signature: gtwpxyhiwuts9d13chxmy9ba6nm68q75 X-Rspamd-Queue-Id: AFFD2D00009A X-Rspamd-Server: rspam01 X-HE-Tag: 1634168748-553097 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 Wed, Oct 13, 2021 at 4:15 PM Roman Gushchin wrote: > [...] > > > > > > Isn't it a bit too aggressive? > > > > > > How about > > > if (WARN_ON_ONCE(gfp & __GFP_ACCOUNT)) > > > > We actually know that kvmalloc(__GFP_ACCOUNT) users exist and can > > trigger bulk page allocator through vmalloc, so I don't think the > > warning would be any helpful. > > > > > gfp &= ~__GFP_ACCOUNT; > > > > Bulk allocator is best effort, so callers have adequate fallbacks. > > Transparently disabling accounting would be unexpected. > > I see... > > Shouldn't we then move this check to an upper level? > > E.g.: > > if (!(gfp & __GFP_ACCOUNT)) > call_into_bulk_allocator(); > else > call_into_per_page_allocator(); > If we add this check in the upper level (e.g. in vm_area_alloc_pages() ) then I think we would need WARN_ON_ONCE(gfp & __GFP_ACCOUNT) in the bulk allocator to detect future users. At the moment I am more inclined towards this patch's approach. Let's say in future we find there is a __GFP_ACCOUNT allocation which can benefit from bulk allocator and we decide to add such support in bulk allocator then we would not need to change the bulk allocator callers at that time just the bulk allocator.