From: Stefan Roesch <shr@devkernel.io>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: kernel-team@fb.com, linux-mm@kvack.org,
linux-trace-kernel@vger.kernel.org, akpm@linux-foundation.org
Subject: Re: [PATCH v1] mm: add tracepoints to ksm
Date: Fri, 10 Mar 2023 11:22:54 -0800 [thread overview]
Message-ID: <qvqwa60k2yt5.fsf@dev0134.prn3.facebook.com> (raw)
In-Reply-To: <20230309172726.14fca32e@gandalf.local.home>
Steven Rostedt <rostedt@goodmis.org> writes:
> On Fri, 10 Feb 2023 13:46:45 -0800
> Stefan Roesch <shr@devkernel.io> wrote:
>
> Sorry for the late reply, I just noticed this (I had the flu when this was
> originally sent).
>
>> +/**
>> + * ksm_remove_ksm_page - called after a ksm page has been removed
>> + *
>> + * @pfn: page frame number of ksm page
>> + *
>> + * Allows to trace the removing of stable ksm pages.
>> + */
>> +TRACE_EVENT(ksm_remove_ksm_page,
>> +
>> + TP_PROTO(unsigned long pfn),
>> +
>> + TP_ARGS(pfn),
>> +
>> + TP_STRUCT__entry(
>> + __field(unsigned long, pfn)
>> + ),
>> +
>> + TP_fast_assign(
>> + __entry->pfn = pfn;
>> + ),
>> +
>> + TP_printk("pfn %lu", __entry->pfn)
>> +);
>> +
>> +/**
>> + * ksm_remove_rmap_item - called after a rmap_item has been removed from the
>> + * stable tree
>> + *
>> + * @pfn: page frame number of ksm page
>> + * @rmap_item: address of rmap_item object
>> + * @mm: address of the process mm struct
>> + *
>> + * Allows to trace the removal of pages from the stable tree list.
>> + */
>> +TRACE_EVENT(ksm_remove_rmap_item,
>> +
>> + TP_PROTO(unsigned long pfn, void *rmap_item, void *mm),
>> +
>> + TP_ARGS(pfn, rmap_item, mm),
>> +
>> + TP_STRUCT__entry(
>> + __field(unsigned long, pfn)
>> + __field(void *, rmap_item)
>> + __field(void *, mm)
>> + ),
>> +
>> + TP_fast_assign(
>> + __entry->pfn = pfn;
>> + __entry->rmap_item = rmap_item;
>> + __entry->mm = mm;
>> + ),
>> +
>> + TP_printk("pfn %lu rmap_item %p mm %p",
>> + __entry->pfn, __entry->rmap_item, __entry->mm)
>> +);
>> +
>> +#endif /* _TRACE_KSM_H */
>> +
>> +/* This part must be outside protection */
>> +#include <trace/define_trace.h>
>> diff --git a/mm/ksm.c b/mm/ksm.c
>> index 56808e3bfd19..4356af760735 100644
>> --- a/mm/ksm.c
>> +++ b/mm/ksm.c
>> @@ -45,6 +45,9 @@
>> #include "internal.h"
>> #include "mm_slot.h"
>>
>> +#define CREATE_TRACE_POINTS
>> +#include <trace/events/ksm.h>
>> +
>> #ifdef CONFIG_NUMA
>> #define NUMA(x) (x)
>> #define DO_NUMA(x) do { (x); } while (0)
>> @@ -655,10 +658,12 @@ static void remove_node_from_stable_tree(struct ksm_stable_node *stable_node)
>> BUG_ON(stable_node->rmap_hlist_len < 0);
>>
>> hlist_for_each_entry(rmap_item, &stable_node->hlist, hlist) {
>> - if (rmap_item->hlist.next)
>> + if (rmap_item->hlist.next) {
>> ksm_pages_sharing--;
>> - else
>> + trace_ksm_remove_rmap_item(stable_node->kpfn, rmap_item, rmap_item->mm);
>
> Instead of dereferencing the stable_node here, where the work could
> possibly happen outside the trace event and in the hot path, could you pass
> in the stable_node instead, and then in the TP_fast_assign() do:
>
> __entry->pfn = stable_node->kpfn;
>
>
To do this, the structure would need to be exposed. Currently the
structure is defined in ksm.c. This is an internal structure that we
most likely don't want to expose. We can get by not printing the pfn
and use the rmap_item to refer back to it, but exposing it directly
here is more convenient for debugging.
Any thoughts?
>> + } else {
>> ksm_pages_shared--;
>> + }
>>
>> rmap_item->mm->ksm_merging_pages--;
>>
>> @@ -679,6 +684,7 @@ static void remove_node_from_stable_tree(struct ksm_stable_node *stable_node)
>> BUILD_BUG_ON(STABLE_NODE_DUP_HEAD <= &migrate_nodes);
>> BUILD_BUG_ON(STABLE_NODE_DUP_HEAD >= &migrate_nodes + 1);
>>
>> + trace_ksm_remove_ksm_page(stable_node->kpfn);
>
> Here too?
>
> -- Steve
>
>> if (stable_node->head == &migrate_nodes)
>> list_del(&stable_node->list);
>> else
>> @@ -1367,6 +1373,8 @@ static int try_to_merge_with_ksm_page(struct ksm_rmap_item *rmap_item,
>> get_anon_vma(vma->anon_vma);
>> out:
>> mmap_read_unlock(mm);
>> + trace_ksm_merge_with_ksm_page(kpage, page_to_pfn(kpage ? kpage : page),
>> + rmap_item, mm, err);
>> return err;
>> }
>>
>> @@ -2114,6 +2122,9 @@ static int try_to_merge_with_kernel_zero_page(struct ksm_rmap_item *rmap_item,
>> if (vma) {
>> err = try_to_merge_one_page(vma, page,
>> ZERO_PAGE(rmap_item->address));
>> + trace_ksm_merge_one_page(
>> + page_to_pfn(ZERO_PAGE(rmap_item->address)),
>> + rmap_item, mm, err);
>> if (!err) {
>> rmap_item->address |= ZERO_PAGE_FLAG;
>> ksm_zero_pages_sharing++;
>> @@ -2344,6 +2355,8 @@ static struct ksm_rmap_item *scan_get_next_rmap_item(struct page **page)
>>
>> mm_slot = ksm_scan.mm_slot;
>> if (mm_slot == &ksm_mm_head) {
>> + trace_ksm_start_scan(ksm_scan.seqnr, ksm_rmap_items);
>> +
>> /*
>> * A number of pages can hang around indefinitely on per-cpu
>> * pagevecs, raised page count preventing write_protect_page
>> @@ -2510,6 +2523,7 @@ static struct ksm_rmap_item *scan_get_next_rmap_item(struct page **page)
>> if (mm_slot != &ksm_mm_head)
>> goto next_mm;
>>
>> + trace_ksm_stop_scan(ksm_scan.seqnr, ksm_rmap_items);
>> ksm_scan.seqnr++;
>> return NULL;
>> }
>> @@ -2661,6 +2675,7 @@ int __ksm_enter(struct mm_struct *mm)
>> if (needs_wakeup)
>> wake_up_interruptible(&ksm_thread_wait);
>>
>> + trace_ksm_enter(mm);
>> return 0;
>> }
>>
>> @@ -2702,6 +2717,8 @@ void __ksm_exit(struct mm_struct *mm)
>> mmap_write_lock(mm);
>> mmap_write_unlock(mm);
>> }
>> +
>> + trace_ksm_exit(mm);
>> }
>>
>> struct page *ksm_might_need_to_copy(struct page *page,
>>
>> base-commit: 234a68e24b120b98875a8b6e17a9dead277be16a
next prev parent reply other threads:[~2023-03-10 19:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-10 21:46 Stefan Roesch
2023-03-09 22:27 ` Steven Rostedt
2023-03-09 22:30 ` Stefan Roesch
2023-03-10 19:22 ` Stefan Roesch [this message]
2023-03-10 20:02 ` Steven Rostedt
2023-03-10 22:34 ` Stefan Roesch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=qvqwa60k2yt5.fsf@dev0134.prn3.facebook.com \
--to=shr@devkernel.io \
--cc=akpm@linux-foundation.org \
--cc=kernel-team@fb.com \
--cc=linux-mm@kvack.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox