From: Matt Wu <email@example.com> To: Masami Hiramatsu <firstname.lastname@example.org>, Christoph Hellwig <email@example.com> Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH] kretprobe scalability improvement Date: Mon, 5 Jul 2021 10:50:17 +0800 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On 2021/7/5 AM7:59, Masami Hiramatsu wrote: > On Sun, 4 Jul 2021 10:16:47 +0100 > Christoph Hellwig <email@example.com> wrote: > >> Would it make sense to just reuse kernel/bpf/percpu_freelist.c for >> kretprobes? > > Hmm, I don't think so. > It seems that what Wuqiang proposed is more efficient than the > percpu_freelist, and it will be less efficient from the viewpoint > of memory usage because kretprobe freelist manages instance pool > among all CPUs (which can be unbalanced, sometimes 95% used by one > core, sometimes used evenly). > > Actually, the best solution is to have per-task fixed-size instance > pool which is shared by all kretprobes (e.g. 4kb/task), because > the instance makes a "shadow stack" for each task. This may consume > more memory but is not increased by adding kretprobes, and should be > scalable. Yes, per-task pool is the best for scalability. How about allocating the kretprobe instance just from stack ? The size of kretprobe instance is very likely to be "small", then most of allocs could be fed quickly from current stack. Expanding default kernel stack by 1 page is also an option, but the impact of memory occupation would be huge, after all the kretprobe is a rare thing and uncertain to normal threads. Regards, Matt Wu
next prev parent reply other threads:[~2021-07-05 2:50 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-03 10:28 wuqiang.matt 2021-07-04 9:16 ` Christoph Hellwig 2021-07-04 23:59 ` Masami Hiramatsu 2021-07-05 2:50 ` Matt Wu [this message] 2021-07-05 6:59 ` Masami Hiramatsu 2021-07-06 1:21 ` Matt Wu 2021-07-06 16:25 ` Masami Hiramatsu 2021-07-07 3:10 ` Matt Wu 2021-07-07 11:26 ` Masami Hiramatsu 2021-07-04 10:18 Matt Wu
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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] kretprobe scalability improvement' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).