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=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 B96CFC433ED for ; Wed, 5 May 2021 18:54:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 342D361168 for ; Wed, 5 May 2021 18:54:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 342D361168 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 95F616B0074; Wed, 5 May 2021 14:54:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 90E806B0075; Wed, 5 May 2021 14:54:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 761E96B0078; Wed, 5 May 2021 14:54:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0055.hostedemail.com [216.40.44.55]) by kanga.kvack.org (Postfix) with ESMTP id 55D646B0074 for ; Wed, 5 May 2021 14:54:06 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 15ED5181AEF10 for ; Wed, 5 May 2021 18:54:06 +0000 (UTC) X-FDA: 78108077292.05.98E3981 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf15.hostedemail.com (Postfix) with ESMTP id 92400A0003B8 for ; Wed, 5 May 2021 18:53:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620240845; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xzcUJiTSMQjqP53U/sK3VcFgjGCdL+Yqx50eNS1EYWE=; b=YUUKtBJaIT4mFCIKtMx/Le+oWLhAR2+CByg60fIUl9+3fsmHGOxN+W42pMiYY7CiIXkv4R brVXYKpT8+QWCp56pCTGlCnRb1y2vslim3W21HQ1ffMSCXh+9SSqLBOcgqbanSU7KZ+Zuk g5aQoN9r99UPKTE/UJth16nRMHpripk= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-101-ItrCAZolMtChtIqkccaXCA-1; Wed, 05 May 2021 14:54:03 -0400 X-MC-Unique: ItrCAZolMtChtIqkccaXCA-1 Received: by mail-qv1-f72.google.com with SMTP id 99-20020a0c80ec0000b029017de514d56fso2341029qvb.17 for ; Wed, 05 May 2021 11:54:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=xzcUJiTSMQjqP53U/sK3VcFgjGCdL+Yqx50eNS1EYWE=; b=duuh8z++hOh34hTqGnu8m1v30OOCwMXcCSZhoaRl+E9hq+QhYIN+dIknrvobjyxmtE iE7uWPgXkhv/vOefaPIaGSL8DVkdf7LEZ4tB1aUSYZd+UjqCJaQRR6yydiSdc+EE7IJr 6AbPPHJXJsHDlQrLAjxp5i7DUhVRHsI7ToQOX0/lcbOWgP21SxWlo/0yqGbqha3q81Wn l+oMsCSQE6Lf65dQAQVjBhR/TQiuR4jwvCVB8rsRyu60XDumlS4yEpuhUvmb83M0xdFP dwSExrRDQ1MmIlhfdkI2Nxu6LGOYFUjgWBeevorSIY3T6dYLT1/DD4RtX6NGRVgvme9T MpZg== X-Gm-Message-State: AOAM531Q5L8vxOl3MtIispeoj/vVdQFklBA7rGiCjC3GtJb6KQt6oAKz ffgDXdSJERVhUU1v3nyrarqSnh5olJMA70Nk2U/rMbEp5iF97bkb1QS9z8QxSfo8IMRqGTC+Dk6 cGmeEyLnjq4aFCw/I4hBQAVQycl3BEV9k1RJknqJcaqnaoRZZdNgXR+JZXuM= X-Received: by 2002:ac8:5913:: with SMTP id 19mr28709929qty.391.1620240842591; Wed, 05 May 2021 11:54:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxO9L95zKwtf/j36yscG23peB8+9h3FxtVHS9v2zg95NN6AFM2hHQYZwFdzzRPV5GbCvpEyEQ== X-Received: by 2002:ac8:5913:: with SMTP id 19mr28709906qty.391.1620240842344; Wed, 05 May 2021 11:54:02 -0700 (PDT) Received: from llong.remote.csb ([2601:191:8500:76c0::cdbc]) by smtp.gmail.com with ESMTPSA id f7sm93995qtm.41.2021.05.05.11.54.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 May 2021 11:54:01 -0700 (PDT) From: Waiman Long X-Google-Original-From: Waiman Long Subject: Re: [PATCH v3 2/2] mm: memcg/slab: Create a new set of kmalloc-cg- caches To: Roman Gushchin Cc: Johannes Weiner , Michal Hocko , Vladimir Davydov , Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , Shakeel Butt , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org References: <20210505154613.17214-1-longman@redhat.com> <20210505154613.17214-3-longman@redhat.com> Message-ID: <5d1683d2-1023-1d1c-91e7-b68549debe1d@redhat.com> Date: Wed, 5 May 2021 14:54:00 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Rspamd-Queue-Id: 92400A0003B8 Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=YUUKtBJa; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf15.hostedemail.com: domain of llong@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=llong@redhat.com X-Rspamd-Server: rspam04 X-Stat-Signature: wdciqm35iw8ucfhbfjejsra6wjy9df91 Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf15; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=216.205.24.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620240839-455191 Content-Transfer-Encoding: quoted-printable 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 5/5/21 2:11 PM, Waiman Long wrote: > On 5/5/21 1:30 PM, Roman Gushchin wrote: > >> >> Btw, I wonder if we also need a change in the slab caches merging=20 >> procedure? >> KMALLOC_NORMAL caches should not be merged with caches which can=20 >> potentially >> include accounted objects. > > Thank for catching this omission. > > I will take a look and modify the merging procedure in a new patch.=20 > Accounting is usually specified at kmem_cache_create() time. Though, I=20 > did find one instance of setting ACCOUNT flag in kmem_cache_alloc(), I=20 > will ignore this case and merge accounted, but unreclaimable caches to=20 > KMALLOC_CGROUP.=20 In mm/slab_common.c: #define SLAB_MERGE_SAME (SLAB_RECLAIM_ACCOUNT | SLAB_CACHE_DMA | \ =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = SLAB_CACHE_DMA32 | SLAB_ACCOUNT) struct kmem_cache *find_mergeable(unsigned int size, unsigned int align, =C2=A0 : =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 if ((flags & SLAB_MERGE_SAME) !=3D (s->flags &=20 SLAB_MERGE_SAME)) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 contin= ue; By making sure kmalloc-cg-* has SLAB_ACCOUNT bit set, a kmemcache=20 created with with SLAB_ACCOUNT may merge with kmalloc-cg-* whereas one=20 without SLAB_ACCOUNT may merge with kmalloc-* for now. So the current=20 code should work fine for most cases. Though, if the ACCOUNT flag is set=20 at kmem_cache_alloc() and the cache happens to be merged into kmalloc-*,=20 we will have the rare case that an objcg pointer array may have to be=20 added to a kmalloc-* cache. However, this is not a common practice, and=20 the three cases (not one, sorry) that I found so far is in arch/x86/kvm/x86.c:=C2=A0=C2=A0=C2=A0=C2=A0 ctxt =3D kmem_cache_zalloc(x8= 6_emulator_cache,=20 GFP_KERNEL_ACCOUNT); fs/hostfs/hostfs_kern.c:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 hi =3D= =20 kmem_cache_alloc(hostfs_inode_cache, GFP_KERNEL_ACCOUNT); virt/kvm/kvm_main.c:=C2=A0=C2=A0=C2=A0 vcpu =3D kmem_cache_zalloc(kvm_vcp= u_cache,=20 GFP_KERNEL_ACCOUNT); We will have to advise against doing that. Cheers, Longman