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 9B935C021B1 for ; Thu, 20 Feb 2025 15:30:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 10B8E280246; Thu, 20 Feb 2025 10:30:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0BA9528023C; Thu, 20 Feb 2025 10:30:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E4F9A280246; Thu, 20 Feb 2025 10:30:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id AEA0928023C for ; Thu, 20 Feb 2025 10:30:32 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 0EDF3C1FEB for ; Thu, 20 Feb 2025 15:30:32 +0000 (UTC) X-FDA: 83140709904.17.11599D5 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf04.hostedemail.com (Postfix) with ESMTP id D31764001D for ; Thu, 20 Feb 2025 15:30:28 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=MB9kQq4D; spf=pass (imf04.hostedemail.com: domain of gmonaco@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=gmonaco@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740065429; a=rsa-sha256; cv=none; b=Gc0uk6NY5ESeNYDCWhMNt08Ds7JhAG2JHihBWZG8SSqTDXpTQXYiWxvGBhe8Ut/9WSZVzK +q/lAFYhvMk8eUvnqtho3NtN2d/cpMeAOEbi2ERdI7DiN1SD2vyq/MLcORE9pR+h4qckuJ rwfK0HfQRuJAdSC75XQJ7VmkFrG/xdg= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=MB9kQq4D; spf=pass (imf04.hostedemail.com: domain of gmonaco@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=gmonaco@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740065429; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=lAiozeIU81OFFoQR/hUjiWSzXTAcrOBltLPNVQ2pJEs=; b=3P8aJDc7P+hM9LM6KVceY+E/z3z0ZGhgRGi/wqkZeqstTxaU2E5jt7eA3gQ49f/g9yWCk5 DR6Q53Api0xhLJ0hStr4vV2sj1igwHg39AfAuQzrct6Rx+uECD9k8tdLYmTYr59l8Pmqzu s+9c3fGaJpfDxsSMCNga86vfccCakxc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1740065428; 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=lAiozeIU81OFFoQR/hUjiWSzXTAcrOBltLPNVQ2pJEs=; b=MB9kQq4DGOaWV1JaHsnmwqp61sXPcZzBBK2LOfaRJHQXL59cst/NbIN2YJmryaEsSmiB+Q cNwP79AkzCOOgXSzt95lt6lHQboB4i615SAPFW56AE3lhNUz5M7U+HeTENPz2dzBiJPmrr Q88CiKML5XAFX77FPVdGGqz9bKLWWck= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-394-XlxJJ1liN6KUTUj45Hze6w-1; Thu, 20 Feb 2025 10:30:26 -0500 X-MC-Unique: XlxJJ1liN6KUTUj45Hze6w-1 X-Mimecast-MFC-AGG-ID: XlxJJ1liN6KUTUj45Hze6w_1740065426 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-38f628ff78eso531433f8f.1 for ; Thu, 20 Feb 2025 07:30:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740065425; x=1740670225; h=mime-version:user-agent:content-transfer-encoding:autocrypt :references:in-reply-to:date:cc:to:from:subject:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=eKTaHaEvddQzU5722WOjI+3oiQgOlFUwv2UlcnuFPYs=; b=NYPGzZtpIuTgfgaHa+bAxo5hsnh7sedmA9G/zg7fX5UgxDSpVBF1d92KwdnGWgWE1a 8RLHiVK6hPK/ZJNhKPph+Z32N+Ra36Agezr+lmPUN3osDrl4pxai27Cvtf8tTTsZuw94 DU3plEP2xyTWFv4etiiDSQubBYPQuglv2WfOU5J6IF0zCLk0uckxManAbFREuxxut+43 ePhlSeYSa+ipfu02e/jSz+/brHUj/hHaQyYO2ywK05d2MIvZ09JB0cdfsmKfE7mY+sxr d/6lHdIWd52pHz/AhluWqTWbgcCvu06vCVunK0k7jAdr5WHYy2u4FdYC0ZbHsVZNhchF BaSg== X-Forwarded-Encrypted: i=1; AJvYcCUNXSLdgqelt5DPCrJ5c0yrjXIGCcD1DCSGVo04NRmg8SXmI/NjgttoNsOcVFZX4UVDg8i0C6nFTQ==@kvack.org X-Gm-Message-State: AOJu0Yxfpuso4GdnYvDBj5OUUxwysF6sTUe7zDQ9/1XJ5yBdA/GrPbkp DhNHYbHT7m8B8Juk4JRWqWP0JCaEBzTPiACD6JBVO37g4Ii1GKIGyhlhzYADqDr3QYNS9J0Q43q fE4diz6BhGJE1IncQXbJkYzckiO2mvPdskgUGQ6aXRDsIJvmb X-Gm-Gg: ASbGnctGv2i/+QYgVWkhAOQojTL4TYVznUYxrE485tFbthR7ZSDJqHOwIc2TqAksGW5 28Qj6lOtJMz5RiyEALBtm7tyIWSLGeQYrUDd4VdFUFV7pIPnqEYk+MWj3CeFeN2zghVmcPAY8KL RDgowePoN/zKNL9eV1PO3Oeyc/bSKMbKaqOXNY5aJ/OVsTjym4TUeUPnHjim4ZrpyA61NHrbJJw P8nIIqd0+aMDwO5+FoU7rfZATk7pdHfj4//ka4SBduXMfWQyl+Hs0E/+sw7fJX5u7+a3CV1EESS eL4kNo27JI1CHiCsuH+2tkOX462rbl4= X-Received: by 2002:a05:6000:4712:b0:38f:32d5:3a92 with SMTP id ffacd0b85a97d-38f614b827bmr3184415f8f.12.1740065425438; Thu, 20 Feb 2025 07:30:25 -0800 (PST) X-Google-Smtp-Source: AGHT+IEMOK8qLm4hhqAb33GHsQI0q1jZIRok0DsJ4GBWPKskL8lGrJaQSLX5IEEJZeKsfMRaXgbN3Q== X-Received: by 2002:a05:6000:4712:b0:38f:32d5:3a92 with SMTP id ffacd0b85a97d-38f614b827bmr3184376f8f.12.1740065424988; Thu, 20 Feb 2025 07:30:24 -0800 (PST) Received: from gmonaco-thinkpadt14gen3.rmtit.csb ([185.107.56.30]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38f561bee3esm6316858f8f.21.2025.02.20.07.30.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Feb 2025 07:30:24 -0800 (PST) Message-ID: Subject: Re: [PATCH v8 1/2] sched: Move task_mm_cid_work to mm work_struct From: Gabriele Monaco To: Mathieu Desnoyers , linux-kernel@vger.kernel.org, Andrew Morton , Ingo Molnar , Peter Zijlstra , "Paul E. McKenney" , linux-mm@kvack.org Cc: Ingo Molnar , Shuah Khan Date: Thu, 20 Feb 2025 16:30:22 +0100 In-Reply-To: References: <20250220102639.141314-1-gmonaco@redhat.com> <20250220102639.141314-2-gmonaco@redhat.com> Autocrypt: addr=gmonaco@redhat.com; prefer-encrypt=mutual; keydata=mDMEZuK5YxYJKwYBBAHaRw8BAQdAmJ3dM9Sz6/Hodu33Qrf8QH2bNeNbOikqYtxWFLVm0 1a0JEdhYnJpZWxlIE1vbmFjbyA8Z21vbmFjb0ByZWRoYXQuY29tPoiZBBMWCgBBFiEEysoR+AuB3R Zwp6j270psSVh4TfIFAmbiuWMCGwMFCQWjmoAFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgk Q70psSVh4TfJzZgD/TXjnqCyqaZH/Y2w+YVbvm93WX2eqBqiVZ6VEjTuGNs8A/iPrKbzdWC7AicnK xyhmqeUWOzFx5P43S1E1dhsrLWgP User-Agent: Evolution 3.54.3 (3.54.3-1.fc41) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 1I9kR944LI-XaI83p403RW3viT7S5duNBWSSeTgM7xA_1740065426 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: D31764001D X-Stat-Signature: kgg3j8guas781dkwppihr9z8sq57m3w4 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1740065428-728219 X-HE-Meta: U2FsdGVkX1+nL1wXIYR54tUDCZ3keIZCFzfld9YehV/Fw/wg9U8VRdDnwq7ODm/YImN8roguKxwXqkKKEYyRqZFli5lexAq5VFESXQsu6VXxKMtdqwG520IrTast2MmYPexarevepqWR3mbsBDsxcXajuv7JAGCow+CEZs+7y+xqxWGSGz9yCIkSZhRjSKwwd3SGE0NDf+Pa6bLNsTkaxjniO7tKpXj2/q4j7h8TwapWoVad5Gp1+aKK+F7vVMgIZxoZbDkyCTa6AujK+Se7JrLKCMm8yenx1Y0607KFe1AEW1CbFAjtCD5tbRlO+HreB+qfgD6I+w6O+SEeYFPgl9dqBF9em3CUSLN1RBiw1ksbfSt1Hf89PlTLhb824kB3/wuJFgUH3VYYXpiJlxTzlJmZH6hicCJSRIGqosBPDqFO8EXRmkFVLxL9Z+F9w5zNw4aGv5HJZOknjQPXoojyvDe+l9btgL1OMnrAV8LZM0b8QBoOpXmzneTPoKT9ucIrXyb8qZThzqk26+CtXfoRc72xqqSepAeM6iutRJAYZRAiRMLYuKHd5PtA254wNNFFo4yYVV8sxGDVLV0yMo60n28P6WuiMqdM25HZOZoC6JyMtVZiDpetg0OOnPZsLChea0g4xOdHiqWwq791BtP5o2TtpgrZ9lOKj16uWIvLNeFvyDLRyzZ71NQ2yJ7AZSZkpZANYVzZ07s4uNOg6mGkHO+HIg8QNiAbqJoR7v44G5aUtuxQrlPUAyRrhunEojNCs6oDzojc2GP92Uupe5nBWg9Hjp4m/HwzZSN6/FPGGCSH5Q5eKSjhhomE/3k9cX8INvECoEG7eO9JzbfRroP7GQlMo48zirkaxILdDFxnFZ5Wz16KXAAfGZfnDhMvCp1EHaj7qonNNiqUmEUJ1XWkpeBPdL+v6rfPA6trG3GnGudGmRYpnjiAZE+TbpJ6b943/XH537mVVMNOaE0x3py d61NS8rG h22lxwhd6SCcot/toBlodCiZlkRVMEYXQeDnRx7sj+fFk4wP/I+C4/PTrJFNZq74rxW6ZMdM857wj6swcbtr27oGKMbgIob9WXi1PIIYpmQYVruxttIIphdZIo3MGqJ+ZskSznzV8U7ITIt7o2/ph6g+5pHOToRFdYhb+zNzwVD45tntcWtcvh7vfn/28dS99uRxFCePO7/AZF8jyeNH9yTw3dyvXZwvEFus9rkoUVeE2gDVliwd1L3KP/GTfY5FBdYF75Qh7vhfVpmK8lQL/HHeVcH4uupd53zsTUc76STn1Bs37mNy/9QSnijmSbDVF4n1M8OAlSwTZkb2jD+58VsLdAcL2HvJMSNRK1uuF0JyKCsRzS1QTzWREv0GZuRLMSTV7VJAogacJDEHxZQMqbkqFD0Zi6gN41Ubdz85QOjAmgA1t4haDLpavSI3zXBWLg1uJ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 Thu, 2025-02-20 at 09:42 -0500, Mathieu Desnoyers wrote: > On 2025-02-20 05:26, Gabriele Monaco wrote: > > Currently, the task_mm_cid_work function is called in a task work > > triggered by a scheduler tick to frequently compact the mm_cids of > > each > > process. This can delay the execution of the corresponding thread > > for > > the entire duration of the function, negatively affecting the > > response > > in case of real time tasks. In practice, we observe > > task_mm_cid_work > > increasing the latency of 30-35us on a 128 cores system, this order > > of > > magnitude is meaningful under PREEMPT_RT. > >=20 > > Run the task_mm_cid_work in a new work_struct connected to the > > mm_struct rather than in the task context before returning to > > userspace. > >=20 > > This work_struct is initialised with the mm and disabled before > > freeing > > it. The queuing of the work happens while returning to userspace in > > __rseq_handle_notify_resume, maintaining the checks to avoid > > running > > more frequently than MM_CID_SCAN_DELAY. > > To make sure this happens predictably also on long running tasks, > > we > > trigger a call to __rseq_handle_notify_resume also from the > > scheduler > > tick (which in turn will also schedule the work item). > >=20 > > The main advantage of this change is that the function can be > > offloaded > > to a different CPU and even preempted by RT tasks. > >=20 > > Moreover, this new behaviour is more predictable with periodic > > tasks > > with short runtime, which may rarely run during a scheduler tick. > > Now, the work is always scheduled when the task returns to > > userspace. > >=20 > > The work is disabled during mmdrop, since the function cannot sleep > > in > > all kernel configurations, we cannot wait for possibly running work > > items to terminate. We make sure the mm is valid in case the task > > is > > terminating by reserving it with mmgrab/mmdrop, returning > > prematurely if > > we are really the last user while the work gets to run. > > This situation is unlikely since we don't schedule the work for > > exiting > > tasks, but we cannot rule it out. > >=20 > > Fixes: 223baf9d17f2 ("sched: Fix performance regression introduced > > by mm_cid") > > Signed-off-by: Gabriele Monaco > > --- > [...] > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > > index 9aecd914ac691..363e51dd25175 100644 > > --- a/kernel/sched/core.c > > +++ b/kernel/sched/core.c > > @@ -5663,7 +5663,7 @@ void sched_tick(void) > > =C2=A0=C2=A0=09=09resched_latency =3D cpu_resched_latency(rq); > > =C2=A0=C2=A0=09calc_global_load_tick(rq); > > =C2=A0=C2=A0=09sched_core_tick(rq); > > -=09task_tick_mm_cid(rq, donor); > > +=09rseq_preempt(donor); > > =C2=A0=C2=A0=09scx_tick(rq); > > =C2=A0=20 > > =C2=A0=C2=A0=09rq_unlock(rq, &rf); >=20 > There is one tiny important detail worth discussing here: I wonder if > executing a __rseq_handle_notify_resume() on return to userspace on > every scheduler tick will cause noticeable performance degradation ? >=20 > I think we can mitigate the impact if we can quickly compute the > amount > of contiguous unpreempted runtime since last preemption, then we > could > use this as a way to only issue rseq_preempt() when there has been a > minimum amount of contiguous unpreempted execution. Otherwise the > rseq_preempt() already issued by preemption is enough. >=20 > I'm not entirely sure how to compute this "unpreempted contiguous > runtime" value within sched_tick() though, any ideas ? I was a bit concerned but, at least from the latency perspective, I didn't see any noticeable difference. This may also depend on the system under test, though. We may not need to do that, what we are doing here is improperly calling rseq_preempt. What if we call an rseq_tick which sets a different bit in rseq_event_mask and take that into consideration while running __rseq_handle_notify_resume? We could follow the periodicity of the mm_cid compaction and, if the rseq event is a tick, only continue if it is time to compact (and we can return this value from task_queue_mm_cid to avoid checking twice). We would be off by one period (commit the rseq happens before we schedule the next compaction), but it should be acceptable: __rseq_handle_notify_resume() { should_queue =3D task_queue_mm_cid(); if (!should_queue && test_bit(RSEQ_EVENT_TICK, &t- >rseq_event_mask)) return; /* go on with __rseq_handle_notify_resume */ } Does it sound like an acceptable solution? Another doubt about this case, here we are worrying about this hypothetical long-running task, I'm assuming this can happen only for: 1. isolated cpus with nohz_full and 1 task (the approach wouldn't work) or 2. tasks with RT priority mostly starving the cpu In 1. I'm not sure the user would really need rseq in the first place, in 2., assuming nothing like stalld/sched rt throttling is in place, we will probably also never run the kworker doing mm_cid compaction (I'm using the system_wq), for this reason it's probably wiser to use the system_unbound_wq, which as far as I could understand is the only one that would allow the work to run on any other CPU. I might be missing something trivial here, what do you think though? Thanks, Gabriele