Message ID | 20230313204825.2665483-1-namhyung@kernel.org |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp1400988wrd; Mon, 13 Mar 2023 13:53:07 -0700 (PDT) X-Google-Smtp-Source: AK7set/0Tpk/jApt/XXCKbB54iWKiBxuG6JOJHgAtbJxTpr8uFqRbWl7lb9xGBOaGNIL9elw2dKM X-Received: by 2002:a05:6a20:c510:b0:cc:5917:c4ec with SMTP id gm16-20020a056a20c51000b000cc5917c4ecmr29250925pzb.23.1678740786963; Mon, 13 Mar 2023 13:53:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1678740786; cv=none; d=google.com; s=arc-20160816; b=ii2d22wIVrCSpM6pLzVFHjTM/myAjEko1pyzQKUzkEmlKdYPNew138WcDOXcSjyoL5 ksdlwvbDESdxTntrJ2K0V6eLGhyBJmPg7eVKeW80e4y7qpaD3UCicwHBIGj5PN+jXa6v zDp8iTEhb4MtDV1bLH0LTueD7s5oJ7IA0TXuqbXnU/e5eHpKd3yRtMn9rdDxPAf1ax1f aqllKY0mWcaxZD4zBuWHusU64QSf53vsyjDS0wbWJaU9V2l1bNr3hgoCxliC02Gml2EG /Z/RaBntDN+EpbqBb62h1kjaROvKJAI/7sfBgl8aRvvB6pkUvmgsEGyQS1G4WmiYxtoh jp8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:sender:dkim-signature; bh=jDEZYmHN4oYDSx2bm7gTBW0Ghq4BZOGxx8ZHt3XAI/o=; b=rEoXASjkx+SB0u4EEM1xKxJeZB+Ob53xq/yhzhwUsKoX8ufXGxUSF38Qzu7KH+VUA/ z7FNuBUH6Tbm+5wvg+wNRRiGevkV2grOLPxpHCAdoDfKDwGjoNcrIpH9RpCUgEsMyCB2 E7/MavUEbPjNbFfVlK2cvqIzpF8hFv9pKAytq7F4FFYlSwZIme296+64KUmcHO1XIe7B 2RDsOK3b4I8p0HTWpFSdDB7V8zAAbvtEMkyPvlQb4JHPStJwPkNk9PR/fJ5T9chVNDk4 tyz68J63vAj/6uxOX3ySWi9wy6hW8bAf3o+621hOSZOElBBzICYZQmAffb3ewSVcmTzX /JGA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=P9rpsY3z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d6-20020a621d06000000b0058623296e77si319541pfd.327.2023.03.13.13.52.51; Mon, 13 Mar 2023 13:53:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=P9rpsY3z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229842AbjCMUsc (ORCPT <rfc822;realc9580@gmail.com> + 99 others); Mon, 13 Mar 2023 16:48:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53092 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229473AbjCMUsa (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 13 Mar 2023 16:48:30 -0400 Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1EE596187; Mon, 13 Mar 2023 13:48:29 -0700 (PDT) Received: by mail-pj1-x1036.google.com with SMTP id d13so3249509pjh.0; Mon, 13 Mar 2023 13:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678740508; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:sender:from:to:cc:subject:date:message-id:reply-to; bh=jDEZYmHN4oYDSx2bm7gTBW0Ghq4BZOGxx8ZHt3XAI/o=; b=P9rpsY3z0Yho+b2Ayeq30KO//EWYdfmC+d+MFlJJrLYrZGrNYmBhAHc9HfGLjTc6KE dNft0C37pRNAGMs2LeZj+TR68Wv11aa+qYm//pqNqtrFHrspk2jn35N3TJekEpVzkPhI VFPbhuVjcR2PP0jZ5d3l+JARTuXiLbuUTfUWvEch8KMbkeChb8OQIOikHvP3JmPPwIr1 mZl+oP+arxVtk7sGc9S//CdwFX21cJp6A6QJmmdBBX9Qcy/FczlllivZbhduScIT3Wyc s0HANYHLV/O//d4wcUPiOtvc2lObsEhAqsPlnvKJilYuYIIiwv3EU2ILBRsyPnbiOCwj 19zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678740508; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:sender:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=jDEZYmHN4oYDSx2bm7gTBW0Ghq4BZOGxx8ZHt3XAI/o=; b=0FW5FJ+aEmHMQkn8h4RQtOjWp4PlfT7OMOWk2HtYxJfSIqU3DAn6yOqNZ3KtSqRgZ/ /zSIeo+xXoRDudvGUmsXZfm4OEt6GMvCi4u4KbspWi845Qg+vo9iiKuwBV53to24q/G+ eZDRVg4y3GNpqY9Y1rlYfLkyAFYjS1s2Cu6RmJFI709VHKVB3aBHDSkyByqXe2ioW0s9 jygiVR4O9imSH3cCPF7PteLJ6WjprQvT9UEzoqgutF5taeqEd8BUa7Trk9LNLYiEFbNp 5L52By2npgMrI7VRVnoWCbO4sFUaLwwY9r2XKGL8UV6ArgTYjl/HYbHuPukRqBhPEhQC wcOQ== X-Gm-Message-State: AO0yUKX5us45sTWIRQZ4ELhK8K2MrpqbKuPQlQ+MQWYzg1MSJMdVuYuQ yHjdyyJhqti4bIN0hUpeAtG47jLQals= X-Received: by 2002:a17:90b:38c3:b0:234:159:4003 with SMTP id nn3-20020a17090b38c300b0023401594003mr35629915pjb.25.1678740508233; Mon, 13 Mar 2023 13:48:28 -0700 (PDT) Received: from moohyul.svl.corp.google.com ([2620:15c:2d4:203:26de:6cd7:2c4f:96d5]) by smtp.gmail.com with ESMTPSA id s12-20020a17090aba0c00b0023af8a3cf6esm265026pjr.48.2023.03.13.13.48.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Mar 2023 13:48:27 -0700 (PDT) Sender: Namhyung Kim <namhyung@gmail.com> From: Namhyung Kim <namhyung@kernel.org> To: Arnaldo Carvalho de Melo <acme@kernel.org>, Jiri Olsa <jolsa@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>, Song Liu <song@kernel.org>, Hao Luo <haoluo@google.com>, Juri Lelli <juri.lelli@redhat.com>, Will Deacon <will@kernel.org>, Waiman Long <longman@redhat.com>, Boqun Feng <boqun.feng@gmail.com>, Stephane Eranian <eranian@google.com>, LKML <linux-kernel@vger.kernel.org>, linux-perf-users@vger.kernel.org, bpf@vger.kernel.org Subject: [PATCH 0/4] perf lock contention: Improve lock symbol display (v1) Date: Mon, 13 Mar 2023 13:48:21 -0700 Message-Id: <20230313204825.2665483-1-namhyung@kernel.org> X-Mailer: git-send-email 2.40.0.rc1.284.g88254d51c5-goog MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760287299546309600?= X-GMAIL-MSGID: =?utf-8?q?1760287299546309600?= |
Series |
perf lock contention: Improve lock symbol display (v1)
|
|
Message
Namhyung Kim
March 13, 2023, 8:48 p.m. UTC
Hello, This patchset improves the symbolization of locks for -l/--lock-addr mode. As of now it only shows global lock symbols present in the kallsyms. But we can add some more lock symbols by traversing pointers in the BPF program. For example, mmap_lock can be reached from the mm_struct of the current task (task_struct->mm->mmap_lock) and we can compare the address of the give lock with it. Similarly I've added 'siglock' for current->sighand->siglock. On the other hand, we can traverse some of semi-global locks like per-cpu, per-device, per-filesystem and so on. I've added 'rqlock' for each cpu's runqueue lock. It cannot cover all types of locks in the system but it'd be fairly usefule if we can add many of often contended locks. I tried to add futex locks but it failed to find the __futex_data symbol from BTF. I'm not sure why but I guess it's because the struct doesn't have a tag name. Those locks are added just because they got caught during my test. It'd be nice if you suggest which locks to add and how to do that. :) I'm thinking if there's a way to track file-based locks (like epoll, etc). Finally I also added a lock type name after the symbols (if any) so that we can get some idea even though it has no symbol. The example output looks like below: $ sudo ./perf lock con -abl -- sleep 1 contended total wait max wait avg wait address symbol 44 6.13 ms 284.49 us 139.28 us ffffffff92e06080 tasklist_lock (rwlock) 159 983.38 us 12.38 us 6.18 us ffff8cc717c90000 siglock (spinlock) 10 679.90 us 153.35 us 67.99 us ffff8cdc2872aaf8 mmap_lock (rwsem) 9 558.11 us 180.67 us 62.01 us ffff8cd647914038 mmap_lock (rwsem) 78 228.56 us 7.82 us 2.93 us ffff8cc700061c00 (spinlock) 5 41.60 us 16.93 us 8.32 us ffffd853acb41468 (spinlock) 10 37.24 us 5.87 us 3.72 us ffff8cd560b5c200 siglock (spinlock) 4 11.17 us 3.97 us 2.79 us ffff8d053ddf0c80 rq_lock (spinlock) 1 7.86 us 7.86 us 7.86 us ffff8cd64791404c (spinlock) 1 4.13 us 4.13 us 4.13 us ffff8d053d930c80 rq_lock (spinlock) 7 3.98 us 1.67 us 568 ns ffff8ccb92479440 (mutex) 2 2.62 us 2.33 us 1.31 us ffff8cc702e6ede0 (rwlock) The tasklist_lock is global so it's from the kallsyms. But others like siglock, mmap_lock and rq_lock are from the BPF. You get get the code at 'perf/lock-symbol-v1' branch in git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git Thanks, Namhyung Namhyung Kim (4): perf lock contention: Track and show mmap_lock with address perf lock contention: Track and show siglock with address perf lock contention: Show per-cpu rq_lock with address perf lock contention: Show lock type with address tools/perf/builtin-lock.c | 46 +++++++---- tools/perf/util/bpf_lock_contention.c | 35 ++++++++- .../perf/util/bpf_skel/lock_contention.bpf.c | 77 +++++++++++++++++++ tools/perf/util/bpf_skel/lock_data.h | 14 ++++ 4 files changed, 152 insertions(+), 20 deletions(-) base-commit: b8fa3e3833c14151a47ebebbc5427dcfe94bb407
Comments
Em Mon, Mar 13, 2023 at 01:48:21PM -0700, Namhyung Kim escreveu: > Hello, > > This patchset improves the symbolization of locks for -l/--lock-addr mode. > As of now it only shows global lock symbols present in the kallsyms. But > we can add some more lock symbols by traversing pointers in the BPF program. > > For example, mmap_lock can be reached from the mm_struct of the current task > (task_struct->mm->mmap_lock) and we can compare the address of the give lock > with it. Similarly I've added 'siglock' for current->sighand->siglock. > > On the other hand, we can traverse some of semi-global locks like per-cpu, > per-device, per-filesystem and so on. I've added 'rqlock' for each cpu's > runqueue lock. > > It cannot cover all types of locks in the system but it'd be fairly usefule > if we can add many of often contended locks. I tried to add futex locks > but it failed to find the __futex_data symbol from BTF. I'm not sure why but > I guess it's because the struct doesn't have a tag name. > > Those locks are added just because they got caught during my test. > It'd be nice if you suggest which locks to add and how to do that. :) > I'm thinking if there's a way to track file-based locks (like epoll, etc). > > Finally I also added a lock type name after the symbols (if any) so that we > can get some idea even though it has no symbol. The example output looks > like below: > > $ sudo ./perf lock con -abl -- sleep 1 > contended total wait max wait avg wait address symbol > > 44 6.13 ms 284.49 us 139.28 us ffffffff92e06080 tasklist_lock (rwlock) > 159 983.38 us 12.38 us 6.18 us ffff8cc717c90000 siglock (spinlock) > 10 679.90 us 153.35 us 67.99 us ffff8cdc2872aaf8 mmap_lock (rwsem) > 9 558.11 us 180.67 us 62.01 us ffff8cd647914038 mmap_lock (rwsem) > 78 228.56 us 7.82 us 2.93 us ffff8cc700061c00 (spinlock) > 5 41.60 us 16.93 us 8.32 us ffffd853acb41468 (spinlock) > 10 37.24 us 5.87 us 3.72 us ffff8cd560b5c200 siglock (spinlock) > 4 11.17 us 3.97 us 2.79 us ffff8d053ddf0c80 rq_lock (spinlock) > 1 7.86 us 7.86 us 7.86 us ffff8cd64791404c (spinlock) > 1 4.13 us 4.13 us 4.13 us ffff8d053d930c80 rq_lock (spinlock) > 7 3.98 us 1.67 us 568 ns ffff8ccb92479440 (mutex) > 2 2.62 us 2.33 us 1.31 us ffff8cc702e6ede0 (rwlock) > > The tasklist_lock is global so it's from the kallsyms. But others like > siglock, mmap_lock and rq_lock are from the BPF. Beautiful :-) And the csets are _so_ small and demonstrate techniques that should be used in more and more tools. Applied, testing. - Arnaldo > You get get the code at 'perf/lock-symbol-v1' branch in > > git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git > > Thanks, > Namhyung > > Namhyung Kim (4): > perf lock contention: Track and show mmap_lock with address > perf lock contention: Track and show siglock with address > perf lock contention: Show per-cpu rq_lock with address > perf lock contention: Show lock type with address > > tools/perf/builtin-lock.c | 46 +++++++---- > tools/perf/util/bpf_lock_contention.c | 35 ++++++++- > .../perf/util/bpf_skel/lock_contention.bpf.c | 77 +++++++++++++++++++ > tools/perf/util/bpf_skel/lock_data.h | 14 ++++ > 4 files changed, 152 insertions(+), 20 deletions(-) > > > base-commit: b8fa3e3833c14151a47ebebbc5427dcfe94bb407 > -- > 2.40.0.rc1.284.g88254d51c5-goog >
Em Mon, Mar 13, 2023 at 06:45:53PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Mon, Mar 13, 2023 at 01:48:21PM -0700, Namhyung Kim escreveu: > > Hello, > > > > This patchset improves the symbolization of locks for -l/--lock-addr mode. > > As of now it only shows global lock symbols present in the kallsyms. But > > we can add some more lock symbols by traversing pointers in the BPF program. > > > > For example, mmap_lock can be reached from the mm_struct of the current task > > (task_struct->mm->mmap_lock) and we can compare the address of the give lock > > with it. Similarly I've added 'siglock' for current->sighand->siglock. Hey, we can go a bit further by using something like pahole's --expand_types and --expand_pointers and play iterating a type members and looking for locks, like: ⬢[acme@toolbox pahole]$ pahole task_struct | grep spinlock_t spinlock_t alloc_lock; /* 3280 4 */ raw_spinlock_t pi_lock; /* 3284 4 */ seqcount_spinlock_t mems_allowed_seq; /* 3616 4 */ ⬢[acme@toolbox pahole]$ Expand points will find mmap_lock: ⬢[acme@toolbox pahole]$ pahole --expand_pointers -C task_struct | grep -B10 mmap_lock } *pgd; atomic_t membarrier_state; atomic_t mm_users; atomic_t mm_count; /* XXX 4 bytes hole, try to pack */ atomic_long_t pgtables_bytes; int map_count; spinlock_t page_table_lock; struct rw_semaphore mmap_lock; ^C ⬢[acme@toolbox pahole]$ ITs just too much expansion to see task_struct->mm, but it is there, of course: ⬢[acme@toolbox pahole]$ pahole mm_struct | grep mmap_lock struct rw_semaphore mmap_lock; /* 120 40 */ ⬢[acme@toolbox pahole]$ Also: ⬢[acme@toolbox pahole]$ pahole --contains rw_semaphore address_space signal_struct key inode super_block quota_info user_namespace blocking_notifier_head backing_dev_info anon_vma tty_struct cpufreq_policy tcf_block ipc_ids autogroup kvm_arch posix_clock listener_list uprobe kernfs_root configfs_fragment ext4_inode_info ext4_group_info btrfs_fs_info extent_buffer btrfs_dev_replace btrfs_space_info btrfs_inode btrfs_block_group tpm_chip ib_device ib_xrcd blk_crypto_profile controller led_classdev cppc_pcc_data dm_snapshot ⬢[acme@toolbox pahole]$ And: ⬢[acme@toolbox pahole]$ pahole --find_pointers_to mm_struct task_struct: mm task_struct: active_mm vm_area_struct: vm_mm flush_tlb_info: mm signal_struct: oom_mm tlb_state: loaded_mm linux_binprm: mm mmu_gather: mm trace_event_raw_xen_mmu_ptep_modify_prot: mm trace_event_raw_xen_mmu_alloc_ptpage: mm trace_event_raw_xen_mmu_pgd: mm trace_event_raw_xen_mmu_flush_tlb_multi: mm trace_event_raw_hyperv_mmu_flush_tlb_multi: mm mmu_notifier: mm mmu_notifier_range: mm sgx_encl_mm: mm rq: prev_mm kvm: mm cpuset_migrate_mm_work: mm mmap_unlock_irq_work: mm delayed_uprobe: mm map_info: mm trace_event_raw_mmap_lock: mm trace_event_raw_mmap_lock_acquire_returned: mm mm_walk: mm make_exclusive_args: mm mmu_interval_notifier: mm mm_slot: mm rmap_item: mm trace_event_raw_mm_khugepaged_scan_pmd: mm trace_event_raw_mm_collapse_huge_page: mm trace_event_raw_mm_collapse_huge_page_swapin: mm mm_slot: mm move_charge_struct: mm userfaultfd_ctx: mm proc_maps_private: mm remap_pfn: mm intel_svm: mm binder_alloc: vma_vm_mm ⬢[acme@toolbox pahole]$ - Arnaldo > > On the other hand, we can traverse some of semi-global locks like per-cpu, > > per-device, per-filesystem and so on. I've added 'rqlock' for each cpu's > > runqueue lock. > > > > It cannot cover all types of locks in the system but it'd be fairly usefule > > if we can add many of often contended locks. I tried to add futex locks > > but it failed to find the __futex_data symbol from BTF. I'm not sure why but > > I guess it's because the struct doesn't have a tag name. > > > > Those locks are added just because they got caught during my test. > > It'd be nice if you suggest which locks to add and how to do that. :) > > I'm thinking if there's a way to track file-based locks (like epoll, etc). > > > > Finally I also added a lock type name after the symbols (if any) so that we > > can get some idea even though it has no symbol. The example output looks > > like below: > > > > $ sudo ./perf lock con -abl -- sleep 1 > > contended total wait max wait avg wait address symbol > > > > 44 6.13 ms 284.49 us 139.28 us ffffffff92e06080 tasklist_lock (rwlock) > > 159 983.38 us 12.38 us 6.18 us ffff8cc717c90000 siglock (spinlock) > > 10 679.90 us 153.35 us 67.99 us ffff8cdc2872aaf8 mmap_lock (rwsem) > > 9 558.11 us 180.67 us 62.01 us ffff8cd647914038 mmap_lock (rwsem) > > 78 228.56 us 7.82 us 2.93 us ffff8cc700061c00 (spinlock) > > 5 41.60 us 16.93 us 8.32 us ffffd853acb41468 (spinlock) > > 10 37.24 us 5.87 us 3.72 us ffff8cd560b5c200 siglock (spinlock) > > 4 11.17 us 3.97 us 2.79 us ffff8d053ddf0c80 rq_lock (spinlock) > > 1 7.86 us 7.86 us 7.86 us ffff8cd64791404c (spinlock) > > 1 4.13 us 4.13 us 4.13 us ffff8d053d930c80 rq_lock (spinlock) > > 7 3.98 us 1.67 us 568 ns ffff8ccb92479440 (mutex) > > 2 2.62 us 2.33 us 1.31 us ffff8cc702e6ede0 (rwlock) > > > > The tasklist_lock is global so it's from the kallsyms. But others like > > siglock, mmap_lock and rq_lock are from the BPF. > > Beautiful :-) > > And the csets are _so_ small and demonstrate techniques that should be > used in more and more tools. > > Applied, testing. > > - Arnaldo > > > You get get the code at 'perf/lock-symbol-v1' branch in > > > > git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git > > > > Thanks, > > Namhyung > > > > Namhyung Kim (4): > > perf lock contention: Track and show mmap_lock with address > > perf lock contention: Track and show siglock with address > > perf lock contention: Show per-cpu rq_lock with address > > perf lock contention: Show lock type with address > > > > tools/perf/builtin-lock.c | 46 +++++++---- > > tools/perf/util/bpf_lock_contention.c | 35 ++++++++- > > .../perf/util/bpf_skel/lock_contention.bpf.c | 77 +++++++++++++++++++ > > tools/perf/util/bpf_skel/lock_data.h | 14 ++++ > > 4 files changed, 152 insertions(+), 20 deletions(-) > > > > > > base-commit: b8fa3e3833c14151a47ebebbc5427dcfe94bb407 > > -- > > 2.40.0.rc1.284.g88254d51c5-goog > > > > -- > > - Arnaldo
Hi Arnaldo, On Tue, Mar 14, 2023 at 5:23 AM Arnaldo Carvalho de Melo <acme@kernel.org> wrote: > > Em Mon, Mar 13, 2023 at 06:45:53PM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Mon, Mar 13, 2023 at 01:48:21PM -0700, Namhyung Kim escreveu: > > > Hello, > > > > > > This patchset improves the symbolization of locks for -l/--lock-addr mode. > > > As of now it only shows global lock symbols present in the kallsyms. But > > > we can add some more lock symbols by traversing pointers in the BPF program. > > > > > > For example, mmap_lock can be reached from the mm_struct of the current task > > > (task_struct->mm->mmap_lock) and we can compare the address of the give lock > > > with it. Similarly I've added 'siglock' for current->sighand->siglock. > > Hey, we can go a bit further by using something like pahole's > --expand_types and --expand_pointers and play iterating a type members > and looking for locks, like: > > ⬢[acme@toolbox pahole]$ pahole task_struct | grep spinlock_t > spinlock_t alloc_lock; /* 3280 4 */ > raw_spinlock_t pi_lock; /* 3284 4 */ > seqcount_spinlock_t mems_allowed_seq; /* 3616 4 */ > ⬢[acme@toolbox pahole]$ > > Expand points will find mmap_lock: > > ⬢[acme@toolbox pahole]$ pahole --expand_pointers -C task_struct | grep -B10 mmap_lock > } *pgd; > atomic_t membarrier_state; > atomic_t mm_users; > atomic_t mm_count; > > /* XXX 4 bytes hole, try to pack */ > > atomic_long_t pgtables_bytes; > int map_count; > spinlock_t page_table_lock; > struct rw_semaphore mmap_lock; > ^C > ⬢[acme@toolbox pahole]$ > > > ITs just too much expansion to see task_struct->mm, but it is there, of > course: > > ⬢[acme@toolbox pahole]$ pahole mm_struct | grep mmap_lock > struct rw_semaphore mmap_lock; /* 120 40 */ > ⬢[acme@toolbox pahole]$ > > Also: > > ⬢[acme@toolbox pahole]$ pahole --contains rw_semaphore > address_space > signal_struct > key > inode > super_block > quota_info > user_namespace > blocking_notifier_head > backing_dev_info > anon_vma > tty_struct > cpufreq_policy > tcf_block > ipc_ids > autogroup > kvm_arch > posix_clock > listener_list > uprobe > kernfs_root > configfs_fragment > ext4_inode_info > ext4_group_info > btrfs_fs_info > extent_buffer > btrfs_dev_replace > btrfs_space_info > btrfs_inode > btrfs_block_group > tpm_chip > ib_device > ib_xrcd > blk_crypto_profile > controller > led_classdev > cppc_pcc_data > dm_snapshot > ⬢[acme@toolbox pahole]$ > > And: > > ⬢[acme@toolbox pahole]$ pahole --find_pointers_to mm_struct > task_struct: mm > task_struct: active_mm > vm_area_struct: vm_mm > flush_tlb_info: mm > signal_struct: oom_mm > tlb_state: loaded_mm > linux_binprm: mm > mmu_gather: mm > trace_event_raw_xen_mmu_ptep_modify_prot: mm > trace_event_raw_xen_mmu_alloc_ptpage: mm > trace_event_raw_xen_mmu_pgd: mm > trace_event_raw_xen_mmu_flush_tlb_multi: mm > trace_event_raw_hyperv_mmu_flush_tlb_multi: mm > mmu_notifier: mm > mmu_notifier_range: mm > sgx_encl_mm: mm > rq: prev_mm > kvm: mm > cpuset_migrate_mm_work: mm > mmap_unlock_irq_work: mm > delayed_uprobe: mm > map_info: mm > trace_event_raw_mmap_lock: mm > trace_event_raw_mmap_lock_acquire_returned: mm > mm_walk: mm > make_exclusive_args: mm > mmu_interval_notifier: mm > mm_slot: mm > rmap_item: mm > trace_event_raw_mm_khugepaged_scan_pmd: mm > trace_event_raw_mm_collapse_huge_page: mm > trace_event_raw_mm_collapse_huge_page_swapin: mm > mm_slot: mm > move_charge_struct: mm > userfaultfd_ctx: mm > proc_maps_private: mm > remap_pfn: mm > intel_svm: mm > binder_alloc: vma_vm_mm > ⬢[acme@toolbox pahole]$ This looks really cool! especially. I'm especially interested in adding super_block and kernfs_root. Let me see how I can add them. Thanks, Namhyung