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 B0AF5C433EF for ; Tue, 12 Oct 2021 18:46:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3788760EE5 for ; Tue, 12 Oct 2021 18:46:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3788760EE5 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=virtuozzo.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id C650B900003; Tue, 12 Oct 2021 14:46:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C13DB900002; Tue, 12 Oct 2021 14:46:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B0259900003; Tue, 12 Oct 2021 14:46:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0018.hostedemail.com [216.40.44.18]) by kanga.kvack.org (Postfix) with ESMTP id A3508900002 for ; Tue, 12 Oct 2021 14:46:06 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 61F1F2D39B for ; Tue, 12 Oct 2021 18:46:06 +0000 (UTC) X-FDA: 78688665132.04.C6C8ACC Received: from relay.sw.ru (relay.sw.ru [185.231.240.75]) by imf22.hostedemail.com (Postfix) with ESMTP id D0EFC1929 for ; Tue, 12 Oct 2021 18:46:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=virtuozzo.com; s=relay; h=Content-Type:MIME-Version:Date:Message-ID:From: Subject; bh=64IcsFb8bBS4pFgFI9KVjfapZy7rEeNKQF8dCkvviYY=; b=pcmeKt+OWhafIWGl+ Rsq0UqWHt6l2z4rGEpWKXORZXiSDMKTtmftnTOedW5rwjcVI2qepA2vleNRBTivfqynFbNdjJVz9i rxsu0SoUkl2/uSmisuOWf21E9oDhshP6OrjfrNC1n8SV04Qxku1PBM1OKoscx4JNdBmVKnrZn6siY =; Received: from [172.29.1.17] by relay.sw.ru with esmtp (Exim 4.94.2) (envelope-from ) id 1maMml-005pmF-PE; Tue, 12 Oct 2021 21:45:59 +0300 Subject: Re: [PATCH mm v3] memcg: enable memory accounting in __alloc_pages_bulk To: Michal Hocko Cc: Johannes Weiner , Vladimir Davydov , Andrew Morton , Shakeel Butt , Mel Gorman , Roman Gushchin , Uladzislau Rezki , Vlastimil Babka , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel@openvz.org References: <0baa2b26-a41b-acab-b75d-72ec241f5151@virtuozzo.com> <60df0efd-f458-a13c-7c89-749bdab21d1d@virtuozzo.com> From: Vasily Averin Message-ID: <3467508f-0f0f-fc28-c973-ad9f0eeb9818@virtuozzo.com> Date: Tue, 12 Oct 2021 21:45:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: D0EFC1929 X-Stat-Signature: y94ort8j6q41ow1m6tpb4tupbime1gbg Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=virtuozzo.com header.s=relay header.b=pcmeKt+O; spf=pass (imf22.hostedemail.com: domain of vvs@virtuozzo.com designates 185.231.240.75 as permitted sender) smtp.mailfrom=vvs@virtuozzo.com; dmarc=pass (policy=quarantine) header.from=virtuozzo.com X-HE-Tag: 1634064365-803942 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 12.10.2021 18:36, Michal Hocko wrote: > On Tue 12-10-21 17:58:21, Vasily Averin wrote: >> Enable memory accounting for bulk page allocator. > > ENOCHANGELOG > > And I have to say I am not very happy about the solution. It adds a very > tricky code where it splits different charging steps apart. > > Would it be just too inefficient to charge page-by-page once all pages > are already taken away from the pcp lists? This bulk should be small so > this shouldn't really cause massive problems. I mean something like > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index b37435c274cf..8bcd69195ef5 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -5308,6 +5308,10 @@ unsigned long __alloc_pages_bulk(gfp_t gfp, int preferred_nid, > > local_unlock_irqrestore(&pagesets.lock, flags); > > + if (memcg_kmem_enabled() && (gfp & __GFP_ACCOUNT)) { > + /* charge pages here */ > + } > + > __count_zid_vm_events(PGALLOC, zone_idx(zone), nr_account); > zone_statistics(ac.preferred_zoneref->zone, zone, nr_account); > In general it looks like we can do it. We can traverse via filled page_array or page_list. For page_array we need to check is the page already accounted (incoming array can contain some pages already, both in the beginning and in middle) For each taken page we can try to charge it. If it was charges successfully -- we will process next page in list/array. When charge fails we need to remove rest of pages from list/array and somehow release them. At present I do not understand how to do it correctly -- perhaps just call free_page() ? Finally, we'll need to adjust nr_account and nr_populated properly. I'll try to implement this tomorrow. Thank you, Vasily Averin