Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp872819pxf; Wed, 7 Apr 2021 13:50:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzxI8RsqyHpwURc9UXtmDJcUEpyXESR1C4/FaHkNxtcNIL2lWelGLDT2bjEnvU4pcu7Adsp X-Received: by 2002:a17:906:bfcc:: with SMTP id us12mr6148775ejb.266.1617828616994; Wed, 07 Apr 2021 13:50:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617828616; cv=none; d=google.com; s=arc-20160816; b=SaSCC+yw4VJi+tWrV0keajE4SrTHygTynpCbmDj+wJclu/KK5/udCHQUpcpWFltKgt tNg53wgl9R9zY4Qd9yWL9ywScdKf+gPyZT5v0zSUpeZqGasA9+WMkuypLUdoqGsj8w9r A2uGgmKjV6BgxR8HpaJwIw+GoZasbemMDQMZxNDGq9hwZ+U5+efy+gYGDWigDzr03BYE SMjNZlDBJrfmpB4h12HjcXMNA9judVobz5u9hB1Ep0+KZZoI2JGUgq1AsnExk7U0PY7H oC0aEpZkB3ue0wYsjyOtElG0YEBmeNgkiFykJTJkJ3BOoUGk2fbjxNc4v2lnRL3OltUG cpSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:references:cc :to:from:subject; bh=4NxS/c3yNhPjjke6sz/VYMscT/fqw5qWLRgCAekMwEU=; b=H/iPtrsXykfdxeDV5Gbb5xl+ZkXr1Z3jNMUuJ3dXJKRQLRAfClprz5BovmniHwK9iH e0StlSNIVFuhlOlbyr1yTETaf02rHxuCeCoybzNkg/gLsLTT0bCOCJX/ABlIFgHpxZ7a 9Mxb3t8f3PDn+dtntkx6llpUk4lM7ROLDwcyErpyV64R/g/k8pNyQthrIus2S3O3gcOe L7WGehaGXpJi33SdlH+dXC2GyFZv6EbProdE2Ec/7Jzq0xSCt9C5gAIx0BMCsRDjFnZ/ p4DSH9wJzvJu44b6eTemeyYBMov+i4t7w4vEar7NYm7/PppBpdHg1nM7pRp0vozIv6z4 y//w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t18si19491347ejj.437.2021.04.07.13.49.53; Wed, 07 Apr 2021 13:50:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346668AbhDGKbE (ORCPT + 99 others); Wed, 7 Apr 2021 06:31:04 -0400 Received: from mx2.suse.de ([195.135.220.15]:49898 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234193AbhDGKbE (ORCPT ); Wed, 7 Apr 2021 06:31:04 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 14A80B0B3; Wed, 7 Apr 2021 10:30:54 +0000 (UTC) Subject: Re: [PATCH v3] mm: slub: move sysfs slab alloc/free interfaces to debugfs From: Vlastimil Babka To: Faiyaz Mohammed , cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: vinmenon@codeaurora.org References: <1617712064-12264-1-git-send-email-faiyazm@codeaurora.org> <2e1f1771-0483-d311-7995-404c837372fc@suse.cz> Message-ID: <623f3165-4bce-8491-c9c4-8eac8404c21a@suse.cz> Date: Wed, 7 Apr 2021 12:30:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <2e1f1771-0483-d311-7995-404c837372fc@suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/6/21 7:15 PM, Vlastimil Babka wrote: > On 4/6/21 2:27 PM, Faiyaz Mohammed wrote: >> alloc_calls and free_calls implementation in sysfs have two issues, >> one is PAGE_SIZE limitiation of sysfs and other is it does not adhere >> to "one value per file" rule. >> >> To overcome this issues, move the alloc_calls and free_calls implemeation >> to debugfs. >> >> Signed-off-by: Faiyaz Mohammed > > Good direction, thanks. But I'm afraid we need a bit more: > > - I don't see debugfs_remove() (or _recursive) used anywhere. When a cache is > destroyed, do the dirs/files just linger in debugfs referencing removed > kmem_cache objects? > - There's a simple debugfs_create_dir(s->name, ...), for each cache while the > sysfs variant handles merged caches with symlinks etc. For consistency, the > hiearchy should look the same in debugfs as it does in sysfs. Oh and one more suggestion. With full seq_file API (unlike sysfs) we should really do the data gathering (to struct loc_track?) part just once per file open, and cache it between individual reads.