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 C5408C433F5 for ; Wed, 13 Oct 2021 17:30:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 700FF610CC for ; Wed, 13 Oct 2021 17:30:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 700FF610CC 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 AD1C3900003; Wed, 13 Oct 2021 13:30:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A81A1900002; Wed, 13 Oct 2021 13:30:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 94955900003; Wed, 13 Oct 2021 13:30:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0163.hostedemail.com [216.40.44.163]) by kanga.kvack.org (Postfix) with ESMTP id 861E7900002 for ; Wed, 13 Oct 2021 13:30:19 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 1B6BE2AEF2 for ; Wed, 13 Oct 2021 17:30:19 +0000 (UTC) X-FDA: 78692102958.13.89F7850 Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by imf17.hostedemail.com (Postfix) with ESMTP id BBCE4F000090 for ; Wed, 13 Oct 2021 17:30:18 +0000 (UTC) Received: by mail-lf1-f41.google.com with SMTP id n8so15037930lfk.6 for ; Wed, 13 Oct 2021 10:30:18 -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=aQOoabUNu0R7IbgTfWQ9QRtHLdgX6BHbDT/1BhoTe9M=; b=btRQMBymcZokHMewh1RWraDTkJdKm+n2ddZG7Lw2znxC/GSJbWy87egZvb6rXSdldy IDXCUqPWaFPmQafIM46OPWdnNjB9VuaJcU33bm66NfS7PNnHNh1b+TblPKadHz2CoEMD OePatUFeM/gA764CLWpwIycRbUOXojpKlgVbJwF8yAqXJsZil9DrYE602MkiWjzKEAiV JxApHT16J9oA9iZW5O/MGbMxz40m7i6boNVwWnxXxV4GLBMC9wMEpT1pvXcbwFxSBbU1 Vg8PN+eyytYs/gund8DNu5b4r0AxEaZ153lRDvRPVV4ruMrlDJeTr+sbnEsxtXA9oiOC gwog== 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=aQOoabUNu0R7IbgTfWQ9QRtHLdgX6BHbDT/1BhoTe9M=; b=QFopv/qbJnF9cuU5sWftO/l7AcrpeLv2fh0ifXB+geFSkWZLCw452N/r6/FjB5r//7 kp8SNEM3iShQN7KHCm3tlG0oBkPs/FcjXlOJj1t1dlRb9yAq8Spy97OhOt+Gn8HaOQ2v 1LSbrJdLSK6JFbVM2XZc5gQNO1/HuDVEChcH7gVOvunjo6f5xKleFgsGUfUGphjZC+Iw Wulg03orf9Mi51AcFD938tCFk8oB8sWr+YMytDt9cF2X8eCJGtlEL8zVi233Aspen2D4 2yBDywV/+lB0jA15pl4DUP1R7ePrG0ZHJpxgYcGmWUFsFakFhRZhpOG45NMoltt3HZlf qX9A== X-Gm-Message-State: AOAM530/VZWeXsgl/ymAIaN+ouwlSdNam5OM1lzTnjWUWJPb0JuM8LOV V5mI/gAW28jgtcUuE0i8yKcM3jVHmdgM9j8WCyjGSw== X-Google-Smtp-Source: ABdhPJwBVo0irDBA2p+/ESUMoecZY8cZKZzIBcJI3jBVFqJ0bJoi/XVS3EPY/CfSxfGkwfEteH52y76Fxi9rAACnhkU= X-Received: by 2002:a05:6512:2204:: with SMTP id h4mr315095lfu.494.1634146216834; Wed, 13 Oct 2021 10:30:16 -0700 (PDT) MIME-Version: 1.0 References: <0baa2b26-a41b-acab-b75d-72ec241f5151@virtuozzo.com> <60df0efd-f458-a13c-7c89-749bdab21d1d@virtuozzo.com> In-Reply-To: From: Shakeel Butt Date: Wed, 13 Oct 2021 10:30:05 -0700 Message-ID: Subject: Re: [PATCH mm v3] memcg: enable memory accounting in __alloc_pages_bulk To: Michal Hocko Cc: Vasily Averin , Johannes Weiner , Vladimir Davydov , Andrew Morton , Mel Gorman , Roman Gushchin , Uladzislau Rezki , Vlastimil Babka , Cgroups , Linux MM , LKML , kernel@openvz.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: BBCE4F000090 X-Stat-Signature: 3m9m54kk7kx81pa5wfy7hp45pm4dahoo Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=btRQMBym; spf=pass (imf17.hostedemail.com: domain of shakeelb@google.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=shakeelb@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1634146218-263922 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 10:16 AM Michal Hocko wrote: > [...] > > > If this is really that complicated (I haven't tried) then it would be > > > much more simple to completely skip the bulk allocator for __GFP_ACCOUNT > > > rather than add a tricky code. The bulk allocator is meant to be used > > > for ultra hot paths and memcg charging along with the reclaim doesn't > > > really fit into that model anyway. Or are there any actual users who > > > really need bulk allocator optimization and also need memcg accounting? > > > > Bulk allocator is being used for vmalloc and we have several > > kvmalloc() with __GFP_ACCOUNT allocations. > > Do we really need to use bulk allocator for these allocations? > Bulk allocator is an bypass of the page allocator for performance reason > and I can see why that can be useful but considering that the charging > path can imply some heavy lifting is all the code churn to make bulk > allocator memcg aware really worth it? Why cannot we simply skip over > bulk allocator for __GFP_ACCOUNT. That would be a trivial fix. > -- Actually that might be the simplest solution and I agree to skip bulk allocator for __GFP_ACCOUNT allocations.