Message ID | 20221025100117.18667-1-wuqiang.matt@bytedance.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp917103wru; Tue, 25 Oct 2022 03:14:06 -0700 (PDT) X-Google-Smtp-Source: AMsMyM44xw5EW8zJddD7qXsXUfpToxhih8ZPGW6iJjh2hvDL+hN1HseaHaE6Vjf8Cu2p8NMaIuVJ X-Received: by 2002:a17:902:820b:b0:185:b9a:8ac1 with SMTP id x11-20020a170902820b00b001850b9a8ac1mr38242006pln.111.1666692846035; Tue, 25 Oct 2022 03:14:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666692846; cv=none; d=google.com; s=arc-20160816; b=ma5ab2UnPW2eYjeyHK7treo79yxZJ5HBSuNwceYSKRGVwrQUXeHDMbmfJUekfsmlru /QEurFo8Uxvd9t+SmSWAQYuC3dCF8m87P+zb0cZoQ0Zd4ughHNeclm44nMKJ+mnBf6qN Fw0/TT8ISNrxxP31ofm9taBL3V8AZ1DoFPoKhqcobdhoiid1bZhRrp8G3mDAvQTNU0O3 vjtLjuWqO8dhkbcu88IdhFvco5AsyVQzFP54vMe5ctylxZwO0sAPslFpPCfwJUfrCRbp Wwe3s8oW+qVBlvIVEyK75d00wMnADz/M0q8nRUJEURXxO1idbBfXX8OX41Q+OVZlwsLP Q7tg== 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:dkim-signature; bh=xjcOdBz7+1s+SY2r8uPJdaB5l1xd98vivegT7WmsGzE=; b=fUjUqZS9yZoO29s8r8w5t7sx+oU/cktWO0d2Q0Rt3rmnH82Y6k/SiB9jxMoXRAPedr S8VhIi2s/LRFP1w8Z7bD2S6IL9gtsdCb0HmzW8miV7CBT8ym3W6XnmKF7yHrcqtieBar tMeW33Rz7e7aqdAbzSGX4RtA5AdJo/Qp6OuRYCjYxa6esfQv0OLfpudVzhr9j0ccPEBr XyO/7Xc3PgU55F+Osv598YecbeA0Vs7Psjrf6KzvYDJoMphk3c8PRb/GKkFj3PJdm4Pk EX0nwesseWbUWf5k3MU6VN17dwRPzc/l79wSIkUd1D6ne994l6efaU4A4OY+4TjAmqd/ Z+9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=uSml8+Dn; 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=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d6-20020a056a0024c600b00565de49c23dsi2682118pfv.105.2022.10.25.03.13.53; Tue, 25 Oct 2022 03:14: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=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=uSml8+Dn; 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=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231911AbiJYKJe (ORCPT <rfc822;lucius.rs.storz@gmail.com> + 99 others); Tue, 25 Oct 2022 06:09:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232310AbiJYKI7 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 25 Oct 2022 06:08:59 -0400 Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B7FCAD0CD6 for <linux-kernel@vger.kernel.org>; Tue, 25 Oct 2022 03:02:27 -0700 (PDT) Received: by mail-vk1-xa35.google.com with SMTP id m18so2776365vka.10 for <linux-kernel@vger.kernel.org>; Tue, 25 Oct 2022 03:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=xjcOdBz7+1s+SY2r8uPJdaB5l1xd98vivegT7WmsGzE=; b=uSml8+DnXdwQjFDu/31djurwZibknnkEBl0HfloAE435L9yijx8dYxLlvQivqhXScV h8hsofYyvULgKM+IrK5ydVpNk2DVBZWOvfe0dOoj5bpPFzmbV3vepj7d5Qt8wwhS1Zzo 1W0glP4SH09ohTe+ZpDakMXVCo6TxCdx2q0M2gRDgTsJ08FXfEBJ1wpZf9V+uvwO6x2W lToztvWSBjLfQRKeQr+2+UEJI6Kb6NDH8nxwTJw5mTjDd/iG6tavzkeL7Ufw28RgKYdI f+MJmcCnHhl64lktXOa2tRzpI8O7seGSWpp3P+RnB0+dPQzUzfmeoO3nn0hgPpScNt05 9pxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xjcOdBz7+1s+SY2r8uPJdaB5l1xd98vivegT7WmsGzE=; b=7qzJ+CipRE2Etgy4vnedEh4b/elLgkPnQ+CzRdcyB2yD8k1aMiMkAJFM4EGYOkQgvY k11LK0rqiEGmF6ZS/IlVp4TL2wBulOySm3mlau19NSb5TgJJlaO5M5HPVZWa65vKNkpQ Tx7niR9WIH6dzK+isMAtsISqRLFBraRT9xQGC5mqMR3/neIay1SNXq2t3knV09mKmS4/ AGrnzY6wLPpygyYaoOcAgfF9tbKXdbwYOMWC/4/v31y0TK0y/sT+0qEJyDgx1bglT0K1 q1RHCIF0pu74XMRxXaiwQzk5PyESH3ZuQqALT3+kdpDfPYLZrytj/pCF32MGmHf06h7B mUqw== X-Gm-Message-State: ACrzQf3nxH48Hk4ZIVcVl4bZZX0arCJI738/0cPWHn0ciSNfbnVEf9PN yXAI7vtLpf+VI8Ct7XeRAvNd/TEt4UqB7g== X-Received: by 2002:a17:902:ec83:b0:17c:afb3:d1ec with SMTP id x3-20020a170902ec8300b0017cafb3d1ecmr37607960plg.172.1666692135945; Tue, 25 Oct 2022 03:02:15 -0700 (PDT) Received: from devtp.bytedance.net ([139.177.225.227]) by smtp.gmail.com with ESMTPSA id p13-20020a170902e74d00b0017a018221e2sm962387plf.70.2022.10.25.03.02.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Oct 2022 03:02:15 -0700 (PDT) From: wuqiang <wuqiang.matt@bytedance.com> To: mhiramat@kernel.org, davem@davemloft.net, anil.s.keshavamurthy@intel.com, naveen.n.rao@linux.ibm.com Cc: linux-kernel@vger.kernel.org, mattwu@163.com, wuqiang <wuqiang.matt@bytedance.com> Subject: [PATCH] kretprobe events missing on 2-core KVM guest Date: Tue, 25 Oct 2022 18:01:17 +0800 Message-Id: <20221025100117.18667-1-wuqiang.matt@bytedance.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham 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?1747654117573034637?= X-GMAIL-MSGID: =?utf-8?q?1747654117573034637?= |
Series |
kretprobe events missing on 2-core KVM guest
|
|
Commit Message
wuqiang.matt
Oct. 25, 2022, 10:01 a.m. UTC
Default value of maxactive is set as num_possible_cpus() for nonpreemptable
systems. For a 2-core system, only 2 kretprobe instances would be allocated
in default, then these 2 instances for execve kretprobe are very likely to
be used up with a pipelined command.
This patch increases the minimum of maxactive to 10.
Signed-off-by: wuqiang <wuqiang.matt@bytedance.com>
---
kernel/kprobes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Tue, 25 Oct 2022 18:01:17 +0800 wuqiang <wuqiang.matt@bytedance.com> wrote: > Default value of maxactive is set as num_possible_cpus() for nonpreemptable > systems. For a 2-core system, only 2 kretprobe instances would be allocated > in default, then these 2 instances for execve kretprobe are very likely to > be used up with a pipelined command. > > This patch increases the minimum of maxactive to 10. > This looks reasonable to me. Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Thank you! > Signed-off-by: wuqiang <wuqiang.matt@bytedance.com> > --- > kernel/kprobes.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/kprobes.c b/kernel/kprobes.c > index 3220b0a2fb4a..b781dee3f552 100644 > --- a/kernel/kprobes.c > +++ b/kernel/kprobes.c > @@ -2211,7 +2211,7 @@ int register_kretprobe(struct kretprobe *rp) > #ifdef CONFIG_PREEMPTION > rp->maxactive = max_t(unsigned int, 10, 2*num_possible_cpus()); > #else > - rp->maxactive = num_possible_cpus(); > + rp->maxactive = max_t(unsigned int, 10, num_possible_cpus()); > #endif > } > #ifdef CONFIG_KRETPROBE_ON_RETHOOK > -- > 2.34.1 >
On Wed, Oct 26, 2022 at 12:33:15AM +0900, Masami Hiramatsu wrote: > On Tue, 25 Oct 2022 18:01:17 +0800 > wuqiang <wuqiang.matt@bytedance.com> wrote: > > > Default value of maxactive is set as num_possible_cpus() for nonpreemptable > > systems. For a 2-core system, only 2 kretprobe instances would be allocated > > in default, then these 2 instances for execve kretprobe are very likely to > > be used up with a pipelined command. > > > > This patch increases the minimum of maxactive to 10. > > This looks reasonable to me. > > Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reasonable yes, but: Is 10 enough? How exactly do those instances get used up without preemption? Perhaps because execve can sleep? If so, perhaps we should use the same logic without preemption that we do with preemption? So maybe just make this line unconditional? - rp->maxactive = max_t(unsigned int, 10, 2*num_possible_cpus()); Also, the behavior was documented in Documentation/trace/kprobes.rst, so perhaps that file should be updated at the same time with the code. > > Signed-off-by: wuqiang <wuqiang.matt@bytedance.com> > > --- > > kernel/kprobes.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/kernel/kprobes.c b/kernel/kprobes.c > > index 3220b0a2fb4a..b781dee3f552 100644 > > --- a/kernel/kprobes.c > > +++ b/kernel/kprobes.c > > @@ -2211,7 +2211,7 @@ int register_kretprobe(struct kretprobe *rp) > > #ifdef CONFIG_PREEMPTION > > rp->maxactive = max_t(unsigned int, 10, 2*num_possible_cpus()); > > #else > > - rp->maxactive = num_possible_cpus(); > > + rp->maxactive = max_t(unsigned int, 10, num_possible_cpus()); > > #endif > > } > > #ifdef CONFIG_KRETPROBE_ON_RETHOOK > > -- > > 2.34.1 > > > > > -- > Masami Hiramatsu (Google) <mhiramat@kernel.org> Thanks, Alexander
On 2022/11/7 21:36, Solar Designer wrote: > On Wed, Oct 26, 2022 at 12:33:15AM +0900, Masami Hiramatsu wrote: >> On Tue, 25 Oct 2022 18:01:17 +0800 >> wuqiang <wuqiang.matt@bytedance.com> wrote: >> >>> Default value of maxactive is set as num_possible_cpus() for nonpreemptable >>> systems. For a 2-core system, only 2 kretprobe instances would be allocated >>> in default, then these 2 instances for execve kretprobe are very likely to >>> be used up with a pipelined command. >>> >>> This patch increases the minimum of maxactive to 10. >> >> This looks reasonable to me. >> >> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> > > Reasonable yes, but: > > Is 10 enough? How exactly do those instances get used up without > preemption? Perhaps because execve can sleep? If so, perhaps we should > use the same logic without preemption that we do with preemption? So > maybe just make this line unconditional? - > > rp->maxactive = max_t(unsigned int, 10, 2*num_possible_cpus()); I agree to make it unconditional, though it could cost a bit more memory. Here's my testcase: a shell script was added to crontab, and the content of the script is: #!/bin/sh do_something_with_magic `tr -dc a-z < /dev/urandom | head -c 10` cron will trigger a series of program executions (4 times every hour). Then we noticed events loss after 3-4 hours of testings. The issue is caused by a burst of series of execve requests. The best number of instances could be different case by case, and should be the user's duty to decide, but num_possible_cpus() as a default value is inadequate. For my testcase, 8 is enough as verified, and 10 is chosen to keep it identical. The handling of execve syscall can be suspended or voluntarily yield up cpu due to i/o or memory resources and then a new execve gets its time slice to start. It could be worse for scenarios of resource throttling or routines that are heavier than execve (though rare as I think). > Also, the behavior was documented in Documentation/trace/kprobes.rst, so > perhaps that file should be updated at the same time with the code. Right, will update in next version. >>> Signed-off-by: wuqiang <wuqiang.matt@bytedance.com> >>> --- >>> kernel/kprobes.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/kernel/kprobes.c b/kernel/kprobes.c >>> index 3220b0a2fb4a..b781dee3f552 100644 >>> --- a/kernel/kprobes.c >>> +++ b/kernel/kprobes.c >>> @@ -2211,7 +2211,7 @@ int register_kretprobe(struct kretprobe *rp) >>> #ifdef CONFIG_PREEMPTION >>> rp->maxactive = max_t(unsigned int, 10, 2*num_possible_cpus()); >>> #else >>> - rp->maxactive = num_possible_cpus(); >>> + rp->maxactive = max_t(unsigned int, 10, num_possible_cpus()); >>> #endif >>> } >>> #ifdef CONFIG_KRETPROBE_ON_RETHOOK >>> -- >>> 2.34.1 >>> >> >> >> -- >> Masami Hiramatsu (Google) <mhiramat@kernel.org> > > Thanks, > > Alexander Best regards, wuqiang
diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 3220b0a2fb4a..b781dee3f552 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -2211,7 +2211,7 @@ int register_kretprobe(struct kretprobe *rp) #ifdef CONFIG_PREEMPTION rp->maxactive = max_t(unsigned int, 10, 2*num_possible_cpus()); #else - rp->maxactive = num_possible_cpus(); + rp->maxactive = max_t(unsigned int, 10, num_possible_cpus()); #endif } #ifdef CONFIG_KRETPROBE_ON_RETHOOK