From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CA2A626FA4B for ; Fri, 17 Jul 2026 13:46:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784296010; cv=none; b=MtHWQ6ZT7Emh2/ac91FW1iB7LlUi7pOlJOjbDIs4SLwmgx3Weo6vmEo9dMjeJLXZIcBIbmgxxtaOCcBTxyAaoY8mIEK407u5pJaR7bt81vuyvv8BmmrkO452rMwL3TyLLW4Ni9VRtXSciTJxd004MT2rxRt2cjJuIDcAWzSzxaI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784296010; c=relaxed/simple; bh=r4+IrlJObP7GHNgsG7i1kKFe+LgU3vXELcSlj9usbmA=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=mKLN8C3S4090ck7T1k1dpn7ShO1JVu/gc75eyoOUDtv6b9yh0G0z2IfJv8rwogd3rci6g4Vn+sMCYA9Qrsna4yWgpKCoCsGdvajf0YYlUIgT+0CH/sZCA6ZN0hBQq+NXiD7YA3v0opJCwM3jdmwxNHvGyNFZYlxvyk3wDIaK+M8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=jLafWwd1; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=JEoryfrT; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="jLafWwd1"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="JEoryfrT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1784296007; h=from:from: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:autocrypt:autocrypt; bh=36Vt7F/I3KQTg1o9rXJVqnyEiEhrV/ViF+I5vNMFZGQ=; b=jLafWwd1TgZqTwu6lOv6HMniz2rGG1zGoAU+nOBYed7ILr3+AA+bHO8XxK6DozgGYY4Mc5 2+CM9tBrltu5hKsp4lsseLt78zeTo8vAKDlyDHm27gTwmou0LTDnabLTx2QxYvOrkltazU T3YbZw9AubfLbmtAlKai72d+Tz6EzFs= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-84-GNpuJ1B_Oaq7Fvzi9Z2ySA-1; Fri, 17 Jul 2026 09:46:46 -0400 X-MC-Unique: GNpuJ1B_Oaq7Fvzi9Z2ySA-1 X-Mimecast-MFC-AGG-ID: GNpuJ1B_Oaq7Fvzi9Z2ySA_1784296005 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-c15d84e3572so412784666b.0 for ; Fri, 17 Jul 2026 06:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1784296005; x=1784900805; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:content-type :autocrypt:references:in-reply-to:date:cc:to:from:subject:message-id :from:to:cc:subject:date:message-id:reply-to:content-type; bh=36Vt7F/I3KQTg1o9rXJVqnyEiEhrV/ViF+I5vNMFZGQ=; b=JEoryfrTsZMDgBWm5Mq2x7h7njpAm3S1SFT5/JP9f++taADVWiVDBmqrGAD5TT3Ti9 UChsGBqTRdYOfaCczIRi4nJGPmCVUdE+vMReoY0Gc0j2JCgxOhtvUWRh/OWhpBxeQ2pF T/iSmnOhVUol22Mn9eedMHH1U701u1P53606qX7yGECUvl9XToXAh9N9ukLqxqwjdQbU LWzthhB+lFgNM2K58b03yC3ttcps/yetg4ymhrnnFX44+JmKhbVi2wMJBB9ZNOLYwS5X LpHCAninK5CK1S4lT+KxjNvc4bka4jyTqK35uY8P4TQpFnS28Jx7AMYR0j68t07h60dJ L+2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784296005; x=1784900805; h=mime-version:user-agent:content-transfer-encoding:content-type :autocrypt:references:in-reply-to:date:cc:to:from:subject:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=36Vt7F/I3KQTg1o9rXJVqnyEiEhrV/ViF+I5vNMFZGQ=; b=splfNK0qKQFPZ5WEqQaA4wZipxxEZ0wAGCjQ5V7oku0m//32QKoQxJQuhPht2oKy+d I80C0w5Yp9MdW70M/AacJvTtG8XQhuPiel68gi8+tCPWDAgt8GfcAaE4D6Pxgk9ad11V ZTP+PorGA6l3XX3bES3Qg3/6vyGgIrlmaEKSzezIDF5lPByhMFPLgPJZfvjzCpHnVc1N G+NLHMV8YYIG12cuwDX8CCmtGV96Qp0Dadh7QxKukn2oWtAVirvRaXvVPmxAA+nqAPef jELwpGb3nA7W/Zm32EDQLyfUTXggXFE/Lf5Y4Vvtz7DYU68MejXZ1Z1BbWuQR3exLC3R e0+g== X-Forwarded-Encrypted: i=1; AHgh+RqI3Nu6x6to3iBJTt4JF458sPKJR6bfmn6wYAoczquhVGholcnXMNtrtfE2Z1JtP9dtF4SrQk9jjJ5D55Y=@vger.kernel.org X-Gm-Message-State: AOJu0Yw6yYyefBk0UF9vm+ZLU6TBF9bm0bH1jiZl6G90kzojSkZHd2a0 d7GUbFC/rK+qcHT9kSBvGaJclcJ9TYuBsVCWed0WLKtsZpskSKU2pJuAfsTChhfT1p/MGdHS3pp MKiwoYKhY2TMFmWeNhcwba8GTB9Zta4yA5wrd4esJBZamd4QcK18s0VteSMkv8VBpnQ== X-Gm-Gg: AfdE7ckkktO3EVaPTUTdR6Mzt//voUvUbJPIADm6Tmz4w445zWVzDxEtBSrp9gfnj9g bYzrPBrGMJL3pSiTVOk6KU1dcr6jUK9L0XJkcXIH1PpTncJN3Q+BEBtbQvnNmdm315YRCVvKbjE WgrTRNgXRTcl/DXESAmuhfb8eWElWlBz1Z0Nr8E6pKeJGgiVyK1cSfEy9Jc61+sY9UeXL3bhQGB QWbKbcN3ZfPYCeXyEjti45yhhAviPP832RvUxR/WXd6ZJFIbRKn0QT7vp7AAC1JsgFuH2fixA/V sGggwiuTL4NcubpKdL+HA3l3ahwxNb5eZNHI5R1Dw17IrDwpdreTCe25zA0AHqn9SHL6C3Trz86 P3N2oipjFulLpwkvsnKgh1vGtRwcTLEzFran3hCsqdDQaThry0mav0mEK0gFZdu7BjdT5jA== X-Received: by 2002:a17:906:3a93:b0:c16:720c:831 with SMTP id a640c23a62f3a-c16b4854cfdmr75100166b.38.1784296005199; Fri, 17 Jul 2026 06:46:45 -0700 (PDT) X-Received: by 2002:a17:906:3a93:b0:c16:720c:831 with SMTP id a640c23a62f3a-c16b4854cfdmr75098366b.38.1784296004477; Fri, 17 Jul 2026 06:46:44 -0700 (PDT) Received: from gmonaco-thinkpadt14gen3.rmtit.csb (212-8-243-115.hosted-by-worldstream.net. [212.8.243.115]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c1740bf91bdsm74296766b.63.2026.07.17.06.46.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Jul 2026 06:46:44 -0700 (PDT) Message-ID: <34e1dfd9b5c8ded4fba878714754813fb60c2431.camel@redhat.com> Subject: Re: [PATCH v4 1/8] rv/da: introduce DA_MON_ALLOCATION_STRATEGY From: Gabriele Monaco To: wen.yang@linux.dev Cc: Nam Cao , linux-trace-kernel@vger.kernel.org, linux-kernel@vger.kernel.org Date: Fri, 17 Jul 2026 15:46:42 +0200 In-Reply-To: <42cda27998fca0ca2573baac60a01ab9620b91f0.1783524627.git.wen.yang@linux.dev> References: <42cda27998fca0ca2573baac60a01ab9620b91f0.1783524627.git.wen.yang@linux.dev> Autocrypt: addr=gmonaco@redhat.com; prefer-encrypt=mutual; keydata=mDMEZuK5YxYJKwYBBAHaRw8BAQdAmJ3dM9Sz6/Hodu33Qrf8QH2bNeNbOikqYtxWFLVm0 1a0JEdhYnJpZWxlIE1vbmFjbyA8Z21vbmFjb0BrZXJuZWwub3JnPoiZBBMWCgBBFiEEysoR+AuB3R Zwp6j270psSVh4TfIFAmjKX2MCGwMFCQWjmoAFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgk Q70psSVh4TfIQuAD+JulczTN6l7oJjyroySU55Fbjdvo52xiYYlMjPG7dCTsBAMFI7dSL5zg98I+8 cXY1J7kyNsY6/dcipqBM4RMaxXsOtCRHYWJyaWVsZSBNb25hY28gPGdtb25hY29AcmVkaGF0LmNvb T6InAQTFgoARAIbAwUJBaOagAULCQgHAgIiAgYVCgkICwIEFgIDAQIeBwIXgBYhBMrKEfgLgd0WcK eo9u9KbElYeE3yBQJoymCyAhkBAAoJEO9KbElYeE3yjX4BAJ/ETNnlHn8OjZPT77xGmal9kbT1bC1 7DfrYVISWV2Y1AP9HdAMhWNAvtCtN2S1beYjNybuK6IzWYcFfeOV+OBWRDQ== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.60.2 (3.60.2-1.fc44) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Wed, 2026-07-08 at 23:38 +0800, wen.yang@linux.dev wrote: > From: Wen Yang >=20 > Per-object DA storage allocation is currently limited to kmalloc on > demand. Add a compile-time selector so monitors can choose among three > strategies: >=20 > =C2=A0 DA_ALLOC_AUTO=C2=A0=C2=A0 (default) - kmalloc per object on the mo= nitor path > =C2=A0 DA_ALLOC_POOL=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 - pre-allocated fixed-size llist pool; > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 selected by defining DA_MON_POOL_SIZE > =C2=A0 DA_ALLOC_MANUAL=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 - caller pre-inserts storage; framework > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 only links the target field >=20 > The pool strategy uses a lock-free llist (cmpxchg, no spinlock) so > pool release is safe from RCU callback context without acquiring a > lock. Moving allocation before the measurement window also prevents > kmalloc latency. Measurement window here is tlob's, remember RV isn't itself a measurement tool (yet, perhaps). And isn't this also happening with other methods? We're trying to do allocation when the monitor starts (so before this measurement window). I'm a bit puzzled since you're mentioning it many times, when have we done /allocations/ from RCU callbacks? We surely do deallocations (kfree_rcu) but allocations are at most in RCU read-side critical sections and it's perfectly fine to take sleeping spinlocks there (that's a special kind of sleep under PREEMPT_RT). Besides I'm not quite sure spinlocks are that bad in RCU callbacks either (kfree surely takes them). I'm not sure what you mean here but I don't think deallocation was ever a problem, was it? > nomiss is updated to DA_ALLOC_MANUAL. >=20 > Suggested-by: Gabriele Monaco > Signed-off-by: Wen Yang > --- > =C2=A0include/rv/da_monitor.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 247 ++++++++= +++++++++++---- > =C2=A0include/rv/ha_monitor.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 = 6 + > =C2=A0kernel/trace/rv/monitors/nomiss/nomiss.c |=C2=A0=C2=A0 6 +- > =C2=A03 files changed, 221 insertions(+), 38 deletions(-) >=20 > diff --git a/include/rv/da_monitor.h b/include/rv/da_monitor.h > index 34b8fba9ecd4..9c9acc123e3b 100644 > --- a/include/rv/da_monitor.h > +++ b/include/rv/da_monitor.h > @@ -14,7 +14,56 @@ > =C2=A0#ifndef _RV_DA_MONITOR_H > =C2=A0#define _RV_DA_MONITOR_H > =C2=A0 > +/* > + * Allocation strategies for RV_MON_PER_OBJ monitors. > + * > + * Select the strategy with a single define before including this header= : > + * > + *=C2=A0=C2=A0 #define DA_MON_POOL_SIZE N=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 - pool mode; N pre-allocated slots. > + *=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Implies DA_ALLOC_POOL > automatically. > + *=C2=A0=C2=A0 #define DA_MON_ALLOCATION_STRATEGY \ > + *=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DA_ALLOC_= MANUAL=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 - manual mode (see below). > + *=C2=A0=C2=A0 (neither)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - auto mode (default). > + * > + * Do not define both DA_MON_POOL_SIZE and DA_MON_ALLOCATION_STRATEGY. > + * > + * DA_ALLOC_AUTO=C2=A0=C2=A0 - lock-free kmalloc on the hot path; unboun= ded capacity. > + * DA_ALLOC_POOL=C2=A0=C2=A0 - pre-allocated fixed-size pool; set by def= ining > DA_MON_POOL_SIZE. > + * DA_ALLOC_MANUAL - caller inserts storage before da_handle_start_event= (); > + *=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the framework only links the target= field. > + */ > +#define DA_ALLOC_AUTO=C2=A0=C2=A0 0 > +#define DA_ALLOC_POOL=C2=A0=C2=A0 1 > +#define DA_ALLOC_MANUAL 2 > + > +#ifdef DA_MON_POOL_SIZE > +#ifdef DA_MON_ALLOCATION_STRATEGY > +#error "Define only one of DA_MON_POOL_SIZE or DA_MON_ALLOCATION_STRATEG= Y" > +#endif > +#if DA_MON_POOL_SIZE =3D=3D 0 > +#error "DA_MON_POOL_SIZE must be non-zero" > +#endif > +#define DA_MON_ALLOCATION_STRATEGY DA_ALLOC_POOL > +#endif Longer ifdefs should have comments to make them readable, like #endif /* DA_MON_POOL_SIZE */ > + > +#ifndef DA_MON_ALLOCATION_STRATEGY > +#define DA_MON_ALLOCATION_STRATEGY DA_ALLOC_AUTO > +#endif > + > +/* > + * Provide a zero default so da_monitor_init() can reference > + * DA_MON_POOL_SIZE in a plain C if() without an #if guard; the > + * compiler eliminates the dead branch. > + */ > +#ifndef DA_MON_POOL_SIZE > +#if DA_MON_ALLOCATION_STRATEGY =3D=3D DA_ALLOC_POOL > +#error "DA_ALLOC_POOL requires DA_MON_POOL_SIZE to be defined and non-ze= ro" > +#endif > +#define DA_MON_POOL_SIZE 0 > +#endif Same here, better to have a comment. > + > =C2=A0#include > +#include > =C2=A0#include > =C2=A0#include > =C2=A0#include > @@ -66,6 +115,16 @@ static struct rv_monitor rv_this; > =C2=A0#define da_monitor_sync_hook() > =C2=A0#endif > =C2=A0 > +/* > + * Per-object teardown hook, called after da_monitor_reset_all() + > + * da_monitor_sync_hook() and before hash_del_rcu() for each entry. > + * All HA timer callbacks have completed at this point. > + * Define before including this header.=C2=A0 Default: no-op. > + */ > +#ifndef da_extra_cleanup > +#define da_extra_cleanup(da_mon) > +#endif > + > =C2=A0/* > =C2=A0 * Type for the target id, default to int but can be overridden. > =C2=A0 * A long type can work as hash table key (PER_OBJ) but will be dow= ngraded to > @@ -404,6 +463,12 @@ struct da_monitor_storage { > =C2=A0 union rv_task_monitor rv; > =C2=A0 struct hlist_node node; > =C2=A0 struct rcu_head rcu; > + /* > + * Mutually exclusive with rcu: rcu is live during the RCU callback > + * flight; free_node when the slot is in da_pool_free_list. > + * Present in all monitors to avoid #if-gating the pool helpers. > + */ I really don't understand much more about it by this comment, perhaps drop it here and make the separate usages clearer later? By the way, if they are /really/ mutually exclusive and you want to save space, why not having them in an anonymous union? > + struct llist_node free_node; > =C2=A0}; > =C2=A0 > =C2=A0#ifndef DA_MONITOR_HT_BITS > @@ -495,18 +560,6 @@ static inline da_id_type da_get_id(struct da_monitor > *da_mon) > =C2=A0 return container_of(da_mon, struct da_monitor_storage, rv.da_mon)- > >id; > =C2=A0} > =C2=A0 > -/* > - * da_create_or_get - create the per-object storage if not already there > - * > - * This needs a lookup so should be guarded by RCU, the condition is che= cked > - * directly in da_create_storage() > - */ > -static inline void da_create_or_get(da_id_type id, monitor_target target= ) > -{ > - guard(rcu)(); > - da_create_storage(id, target, da_get_monitor(id, target)); > -} > - > =C2=A0/* > =C2=A0 * da_fill_empty_storage - store the target in a pre-allocated stor= age > =C2=A0 * > @@ -537,15 +590,79 @@ static inline monitor_target > da_get_target_by_id(da_id_type id) > =C2=A0 return mon_storage->target; > =C2=A0} > =C2=A0 > +/* > + * Lock-free llist (cmpxchg) rather than kmem_cache/mempool: on > + * PREEMPT_RT spinlock_t becomes a sleeping lock, which is forbidden > + * in the rcuc kthread context where RCU callbacks run. This comment kind of implies we were using a kmem_cache, it's great for a changelog and helped me understand why you're doing this, but doesn't belong to the final version as is. > + * > + * Multiple producers (any context, any CPU) call llist_add; a single > + * consumer (llist_del_first, serialised by the monitor's start lock) Which monitor's start lock? There is no such a thing defined anywhere, maybe you wanted to say that monitors using this allocation scheme MUST lock during their start event. This by the way needs to be a global lock among all instances of the monitor (as you're indeed doing in tlob). With that in mind, I don't really see how this is better than the original mempool: you still need to lock. There's nothing wrong in freeing stuff from RCU callbacks, that's what they're for. > + * needs no additional synchronisation. > + * > + * Per-TU statics: each PER_OBJ monitor gets its own pool instance; > + * da_pool_storage and da_pool_free_list are NULL/empty and the pool > + * paths are dead code for non-pool monitors. > + */ > +static struct da_monitor_storage *da_pool_storage; > +static LLIST_HEAD(da_pool_free_list); ... > +++ b/kernel/trace/rv/monitors/nomiss/nomiss.c > @@ -17,8 +17,8 @@ > =C2=A0 > =C2=A0#define RV_MON_TYPE RV_MON_PER_OBJ > =C2=A0#define HA_TIMER_TYPE HA_TIMER_WHEEL > -/* The start condition is on sched_switch, it's dangerous to allocate th= ere > */ > -#define DA_SKIP_AUTO_ALLOC > +/* Allocate storage in sched_setscheduler; sched_switch is too hot to al= loc. > */ > +#define DA_MON_ALLOCATION_STRATEGY DA_ALLOC_MANUAL > =C2=A0typedef struct sched_dl_entity *monitor_target; > =C2=A0#include "nomiss.h" > =C2=A0#include > @@ -214,7 +214,7 @@ static void handle_sys_enter(void *data, struct pt_re= gs > *regs, long id) > =C2=A0 if (p->policy =3D=3D SCHED_DEADLINE) > =C2=A0 da_reset(EXPAND_ID_TASK(p)); > =C2=A0 else if (new_policy =3D=3D SCHED_DEADLINE) > - da_create_or_get(EXPAND_ID_TASK(p)); > + da_create_empty_storage(get_entity_id(&p->dl, task_cpu(p), > DL_TASK)); I'm starting to doubt this is the right thing to do. We do have the target (p) and that function doesn't check if the id already has a storage (which shouldn't happen but well, doesn't hurt checking). This simplification is probably just not worth it, and doesn't look related to the rest of the change. Thanks, Gabriele