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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 92F59C30653 for ; Thu, 4 Jul 2024 06:40:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 27B368D0003; Thu, 4 Jul 2024 02:40:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 22BE68D0001; Thu, 4 Jul 2024 02:40:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F3A38D0003; Thu, 4 Jul 2024 02:40:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id EC4DE8D0001 for ; Thu, 4 Jul 2024 02:40:26 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 9BDFC140FF5 for ; Thu, 4 Jul 2024 06:40:26 +0000 (UTC) X-FDA: 82301121252.26.BF35624 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf15.hostedemail.com (Postfix) with ESMTP id 374E5A000A for ; Thu, 4 Jul 2024 06:40:22 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=none; spf=pass (imf15.hostedemail.com: domain of lihongbo22@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=lihongbo22@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720075205; h=from:from:sender: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=gBU3pNdWQ7ymtNS2J25zKyIUf2zwLWaG8Pu1wDrV/Ng=; b=COVnScONU72C7cXdWs7yzxBE8f6C/BkpFomAACGAVjun7ZsXwSB0+tOoMZE4OOTF5nx0BZ I9ipyd4dmrEE570r1potUzg8Y+HsZkpqN0CaGfcMxjq8VqePnS/vGPUEA+hcNmqqiMWwXH wYvOVsoNcbUl9ssJFDgTajSiQTg/S+k= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; spf=pass (imf15.hostedemail.com: domain of lihongbo22@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=lihongbo22@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720075205; a=rsa-sha256; cv=none; b=UJyBkd8TDcm7NLDFzQkiz7NND9rKnQSm/UtWTRa70MJrPgw7TMK4aPziAe9sZ2O4AWUXIo GEI61IQZ5T3ck0HPTiFmGQyop+6MVsk7EzxauZXXO88eJwwrnnfLTTQit3Mnv9SJ4wPv9t iTzqtbsQ3du7yfVE4RDw3PEMTmnNl+4= Received: from mail.maildlp.com (unknown [172.19.88.105]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4WF6NJ1McjzZhZg; Thu, 4 Jul 2024 14:35:44 +0800 (CST) Received: from dggpeml500022.china.huawei.com (unknown [7.185.36.66]) by mail.maildlp.com (Postfix) with ESMTPS id BFADD1400D1; Thu, 4 Jul 2024 14:40:18 +0800 (CST) Received: from [10.67.111.104] (10.67.111.104) by dggpeml500022.china.huawei.com (7.185.36.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 4 Jul 2024 14:40:18 +0800 Message-ID: Date: Thu, 4 Jul 2024 14:40:17 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] hugetlbfs: support tracepoint To: Matthew Wilcox CC: , , , , , , References: <20240704030704.2289667-1-lihongbo22@huawei.com> <20240704030704.2289667-2-lihongbo22@huawei.com> Content-Language: en-US From: Hongbo Li In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.111.104] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpeml500022.china.huawei.com (7.185.36.66) X-Stat-Signature: 4bmssxmq4jdkm84imnsfxeucyoa7brn8 X-Rspam-User: X-Rspamd-Queue-Id: 374E5A000A X-Rspamd-Server: rspam02 X-HE-Tag: 1720075222-473035 X-HE-Meta: U2FsdGVkX1/oix5EB0mD9DIAZbVQC5hjOtIGqq/n4tVYt3OHw64qP5JgaCH/hIGpT8ihXNH/QfqYTpZ4QIurotg9qMbT2Ax0mbIeYl3jueUxEHUHlHgJikqLkN3MsavDCPbwcUXc2UxlKqbx+YaZpVJHzJwm1nVdrWOWkmm7LfR1NpeVUBzRrO6z/OlMWe6dvqiEXf9m2wxNrvh7Hm7n+1ExhsFe+i1lM1FStjn5Xf5E0NrWD9kEOR13MtR59yLBoHDgjJO61GMwg2kS++2cis5mIJZEBQ6kRFcoPh+A4WERXiEvj6WKyXI8bJzr7PVcD153U8WfNESmycKe9fbVy+9lMZcIptCoOFTI9emWfRHSQKP063jNq5sdmtpJnwvvptKEATl/dlaPM8tMiCsWZjhKHYsEiP7+Jir7XAHReFyOKD5Cy95FUICTmkqzEgP/JniJIFHapdKhGOcXPwMbX2CNToZLIp6+4O5yymoaJSiyTnQPARAV6L6339jH9mNKGO7BDacmd/NqunhLXChHxDwmvtMvRtAB5gFaIfW1lcAtpMbzhPgMnbpqRhCPzflZLkd5U6KA6jCiXW8UHeVjReBy45CVXSlolG+VCumd+T3Nzai+ODWDuaLOgBKpsBqjoxQJ2pf+IjJSJEoqk0zmL/1l8bunaTuiyEE8RrxwU001LIYdhC0SLXvocKTMBHF0qfaQm4kKXsdyDqPcGM4M+/1TXGO/E7tDUXK8T4nX/vBzpWnRwpDgdguQ1KlV2peGAL//0uCrpQbMdoDBR7TmOimd0cKR/Htf8nZJx6u33y3NyKFo7EsB3h5aUnuW0sDPhcUO3toMNl0HH5tQ4/HG0x0sx09TfkKEC4qco4tnjf6zlaiSQ2Cbti4yraQtxdQtWEMTFTISqq6r/nmWoMsdrOKOOMcYRAmXA20W27mG17lqEiS/ea3JhYp6E5hSRP/0U27dZQRgbkOfhytyBfW e+MvUp8t PDfaYR89bWGlurf5fC7TEZU3mxMBMHTZ1EOp+bnfmuNS6G1+SFFe1HAW36Prnc/Sfq3MbP8Qn3g0AMY0XhCi8B6Bv6pU85m55YaGuJwk+41c+gThtmafb/+8x6kBP7guleZmHxyF8XAkp8oVL0tSI8sKNTcHoOlgZ5Tt3wYWttjHHv+I= 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: List-Subscribe: List-Unsubscribe: On 2024/7/4 11:37, Matthew Wilcox wrote: > On Thu, Jul 04, 2024 at 11:07:03AM +0800, Hongbo Li wrote: >> + TP_printk("dev = (%d,%d), ino = %lu, dir = %lu, mode = 0%o", >> + MAJOR(__entry->dev), MINOR(__entry->dev), >> + (unsigned long) __entry->ino, >> + (unsigned long) __entry->dir, __entry->mode) > > erofs and f2fs are the only two places that print devices like this. > > "dev=%d:%d inode=%lx" > > Why do we need dir and mode? Thanks for reviewing! Here dir and mode are used to track the creation of the directory tree. > > Actually, why do we need a tracepoint on alloc_inode at all? What > does it help us debug, and why does no other filesystem need an > alloc_inode tracepoint? > In fact, f2fs and ext4 have added this tracepoint such as trace_f2fs_new_inode(in f2fs) and trace_ext4_allocate_inode(in ext4). This can trace the lifecycle of an inode comprehensively. These tracepoints are used to debug some closed application scenarios, and also helping developers to debug the filesystem logic in hugetlbfs. Thanks, Hongbo