From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7932DC25B74 for ; Thu, 30 May 2024 11:10:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DB39D6B0098; Thu, 30 May 2024 07:10:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D3BDD6B0099; Thu, 30 May 2024 07:10:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB5106B009B; Thu, 30 May 2024 07:10:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 9A2F46B0098 for ; Thu, 30 May 2024 07:10:50 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1C4B51407BD for ; Thu, 30 May 2024 11:10:50 +0000 (UTC) X-FDA: 82174794660.08.078A991 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by imf08.hostedemail.com (Postfix) with ESMTP id 10C27160018 for ; Thu, 30 May 2024 11:10:47 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=layalina-io.20230601.gappssmtp.com header.s=20230601 header.b="asKJ/2Fi"; dmarc=none; spf=pass (imf08.hostedemail.com: domain of qyousef@layalina.io designates 209.85.221.42 as permitted sender) smtp.mailfrom=qyousef@layalina.io ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717067448; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Kiy02xbpkVoe0jsA57DQLD//qIOyPVkR19TcyOZjzlw=; b=P4sTM5kN0bRj/njWAtuO42EnpZTUvomUK88p5nHfK9P1hY9k06JqOqwmqBZLDAOtm8fNtY P26xRgWy8P+u44fIgONHbMJR7LdTub/6mST3DQfFG68NvOCGgqjjuHJMcMAE0+Q8uwtR+7 ZZQNpQLoS1QyV+ULltQb7RxmynhyRUk= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=layalina-io.20230601.gappssmtp.com header.s=20230601 header.b="asKJ/2Fi"; dmarc=none; spf=pass (imf08.hostedemail.com: domain of qyousef@layalina.io designates 209.85.221.42 as permitted sender) smtp.mailfrom=qyousef@layalina.io ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717067448; a=rsa-sha256; cv=none; b=B0z793xNlZJjqSSqfoDkqVIz8cKGhY4qA1LsU6IoclIyw+Lurhb8ZeZ5ioHOPQ5PpFW94L /yzb/bKus6SbNjd0cfDyg3OmxkUyHNthEY7NcaV+2EqhgfYz7yQy3m0TnNNHZnUAdt9ggK GufO8Tvg1Y0kyzkFKh1KoSTPnsRD7u0= Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-35dc984b3d2so350467f8f.1 for ; Thu, 30 May 2024 04:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=layalina-io.20230601.gappssmtp.com; s=20230601; t=1717067446; x=1717672246; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Kiy02xbpkVoe0jsA57DQLD//qIOyPVkR19TcyOZjzlw=; b=asKJ/2Fi/MB4nTqJoSKckFX9BobohNV9G9usohnUHBXWPlF8LS41NWwZ4jT6phEXoj EBdeEd5HWOI0ojbqYswvyJh9G2JX+4AtdRyFYUBBYQWLhQqhGnUJ/0AraqP5HHFRZzCw XN/j8jjLvmVk0anrDKhW8ToeD9bnAyjkvYFXXA6HxSS0JFmJup487D2nvwDtHxs6HWSe f7Gq6gHq1UHz/1XKDbIjdel1p1AZvQKcQdFa4iB+ZaQUa84CpoyqmSFdGcDSk8w1caAq CXgHzlFgBEz5izPkZll7Lxzfb7uW1+HjvJ0vHan/q43ZuYuE6gtNvWuoPkOLYqXhRQhs A7bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717067446; x=1717672246; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Kiy02xbpkVoe0jsA57DQLD//qIOyPVkR19TcyOZjzlw=; b=NeGNL93OBAWZ2CP/flafiyOczzDYdQYU4iTjDhxe3VcW6ga9YHlTiJlwWip/xxTm2z ZOq1SKSCgMYRrTqlCa923WP+q+38Qkrqbdwy/HscGbj+0aZ02Xs3ihC17709Pn3VbBkc 6qF1ySo/pk9L2uMHI4dGaaO/jaGrnLJpGM++H4LHXSMMbg0coTkUYKqr5mmMaUfyYGo8 wFm1M/mDFCKlTOST28P2IEn/0DS+uOC1ynpIb6G7cg50qLKPd6cw9ShEHZYBOYo77aZL TK58I7/iGTy7HqXlbTpugPz1nipfbqM3dXcdJGUuhIFbh6Z6J7sAKu2t3qwePf0/njhT t2xQ== X-Forwarded-Encrypted: i=1; AJvYcCXaWwSarmbzSWx7QOleP/hdOhT+8M0v+00Kn8AL226chP4qDsh0ToQyWiuGvyguI5WjrmcN4LkG88I5bZ/P2J3RWvU= X-Gm-Message-State: AOJu0YyEf/GhYdakeEVKE267fJwo6dcANZAZ/njxjZrxL/cBQdTa40P/ IRITVeY11/krkDUIqcmdSd1ND+I1FDUbVGFQWO6dqtGAtW/cy/7aaG8mGxG4114= X-Google-Smtp-Source: AGHT+IGchwI3vGbp2XfZ0nNpV0truuCoIeo7BGZQIyTNoxwDO/cF3FCmMTdbSH9KXzYGNrWg5l0NwA== X-Received: by 2002:a5d:6acd:0:b0:354:faec:c9e4 with SMTP id ffacd0b85a97d-35dc00c7d46mr2029957f8f.60.1717067446409; Thu, 30 May 2024 04:10:46 -0700 (PDT) Received: from airbuntu (host81-157-90-255.range81-157.btcentralplus.com. [81.157.90.255]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-357ad6c2fabsm13518620f8f.83.2024.05.30.04.10.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 May 2024 04:10:45 -0700 (PDT) Date: Thu, 30 May 2024 12:10:44 +0100 From: Qais Yousef To: Sebastian Andrzej Siewior Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Steven Rostedt , Vincent Guittot , Daniel Bristot de Oliveira , Thomas Gleixner , Alexander Viro , Christian Brauner , Andrew Morton , Jens Axboe , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-mm@kvack.org, Phil Auld Subject: Re: [PATCH v2] sched/rt: Clean up usage of rt_task() Message-ID: <20240530111044.d4jegeiueizvdjrg@airbuntu> References: <20240515220536.823145-1-qyousef@layalina.io> <20240521110035.KRIwllGe@linutronix.de> <20240527172650.kieptfl3zhyljkzx@airbuntu> <20240529082912.gPDpgVy3@linutronix.de> <20240529103409.3iiemroaavv5lh2p@airbuntu> <20240529105528.9QBTCqCr@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20240529105528.9QBTCqCr@linutronix.de> X-Rspamd-Queue-Id: 10C27160018 X-Stat-Signature: 965cihdsu3q8cur6x11xwgipm514wfb1 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1717067447-937803 X-HE-Meta: U2FsdGVkX1/vluiqi8u/WGYLO9pJtsn7mnkwXzEz/Ggdnrw0Sz/kidGdDVy0TOmUT4dHf/lU0DzWaIERnw9sOQ86E3RL5ixvWr2akl/FbnmRhRoPx0v0dGzBZGyaChMc92UK3ID6UuWrRJDpbafYXkUg0mI6M3Bt/cOsc4YGeR937qziv/yr10P6eJSPpBRUN8D4bgXC0J7SL8j4on53AZKiOtO7bTHlpwDn1byx/lNNtiknqzFEQ1rOr6cavfST67umoUvIr3odKOzcxl1PJtydaWB2bcCLzW5HRDYN00tECgTN8sKWyfT3ihk3MD8pAat7SWujDvcU9Iv6uYkRYjrajgYpFPnQMSE4tHqF4O7m2R7JZo6kjrqFlQqMCVC4Yk9qhuisiBq6FxYL3leH6J0eJkk/BuvH2Z3nsD1XFW+/qPBonAqjXYtxCCCbzA3QjJN1glSdQGyjjJYTNgqj44Q26gIls414esBRkYhI339sNtivNAamdxSDlfljdxlDa9iVxRa62w1V9TfSzCa1wnB1Fi6EjeZXYLOBSlP7j+ZVwAc/uxXZSU4jdjaV7ui7eCTt1EHjnPrR4pWsW9UeImkyvQBieeWCYWyrftdZX2VbfjRwn9y7bcRlVVlIECPf2ox9xradcxWIGuhVNltn5g/uG+yHjVUDZcTX0v6+FD88TwurxoHc9oD5Z2ZTXjwvsizAsHElw8VDaO59pYKoajlHmEWAjAQLxLW4DkYPjnQRsftn33jkWFjRuqr8mO7b0+oPGFNTpKEbvvHbe2MIwb6neW8w0bDHBbi4YbJ2uE7OF5ZQXVKQkxSOu+zyYCNVp1Ui31D0gmpQcdTrwqYdH3b2Q3bxwBd4O/PXhGa0Mt5qoY1seR9U6duYAUNYSr1AiQ5mmGVcdv5UYm7SGA42EbQKOL03UA8ok8b3vm7AcsaLQC8vWStUcnto8DAD04mMvKX/Db+qPf0AlQgQ16G 2fCUCHX/ 9kFqtM82DWATPNZ0g+k9glQwu3Hmw94tenVHDJ1NzNJ7YRrBxGiJDrwUYsEd58U29rij15rW3qQQyTwwTqkxfAiTs+94i9cdBJcJokipwCjlJnz79reZT1+QHX0XfFnXP4WJitkiflaVUIwa9nZRcAW5jJMAjyg3K6zv8yVpKAA0w1nb3IZmjEdWFRjQ3STmf5dsO+XckTqgiIK5QbCVrxu/ZrAbcU13VyYl/5uWrkuqptzfOIE+94+cqnuqoJAyt/rdIuSCfvTmgYzUsyQ7d/It2SHjvOa21lv5rTkL1jEE043k47c+If1+Ybd36ZmOEwXasbFWghpHwaGdUJz2QgpotWulIFPAlvQJ5MOov8wedp6K9/rNhndQenPTHQwjIOPMPzCjJx4YY/kde9QaNy+LYaNnedcAjk1uEQOL6LaQFwiQnyDcfIm0QJapEM3krg6sh X-Bogosity: Ham, tests=bogofilter, spamicity=0.000045, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 05/29/24 12:55, Sebastian Andrzej Siewior wrote: > On 2024-05-29 11:34:09 [+0100], Qais Yousef wrote: > > > behaviour. But then it is insistent which matters only in the RT case. > > > Puh. Any sched folks regarding policy? > > > > I am not sure I understood you here. Could you rephrase please? > > Right now a SCHED_OTHER task boosted to a realtime priority gets > slack=0. In the !RT scenario everything is fine. > For RT the slack=0 also happens but the init of the timer looks at the > policy instead at the possible boosted priority and uses a different > clock attribute. This can lead to a delayed wake up (so avoiding the > slack does not solve the problem). > > This is not consistent because IMHO the clock setup & slack should be > handled equally. So I am asking the sched folks for a policy and I am > leaning towards looking at task-policy in this case instead of prio > because you shouldn't do anything that can delay. Can't we do that based on is_soft/is_hard flag in hrtimer struct when we apply the slack in hrtimer_set_expires_range_ns() instead? (not compile tested even) diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h index aa1e65ccb615..e001f20bbea9 100644 --- a/include/linux/hrtimer.h +++ b/include/linux/hrtimer.h @@ -102,12 +102,16 @@ static inline void hrtimer_set_expires(struct hrtimer *timer, ktime_t time) static inline void hrtimer_set_expires_range(struct hrtimer *timer, ktime_t time, ktime_t delta) { + if (timer->is_soft || timer->is_hard) + delta = 0; timer->_softexpires = time; timer->node.expires = ktime_add_safe(time, delta); } static inline void hrtimer_set_expires_range_ns(struct hrtimer *timer, ktime_t time, u64 delta) { + if (timer->is_soft || timer->is_hard) + delta = 0; timer->_softexpires = time; timer->node.expires = ktime_add_safe(time, ns_to_ktime(delta)); }