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 D1FC1E77188 for ; Thu, 26 Dec 2024 09:04:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B64296B007B; Thu, 26 Dec 2024 04:04:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B155E6B0083; Thu, 26 Dec 2024 04:04:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9DB906B0085; Thu, 26 Dec 2024 04:04:28 -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 83BDE6B007B for ; Thu, 26 Dec 2024 04:04:28 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 341B01A172D for ; Thu, 26 Dec 2024 09:04:28 +0000 (UTC) X-FDA: 82936523208.15.86BE0CB Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf20.hostedemail.com (Postfix) with ESMTP id B92FD1C0003 for ; Thu, 26 Dec 2024 09:03:42 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=KW3CdHF6; spf=pass (imf20.hostedemail.com: domain of gmonaco@redhat.com designates 170.10.129.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=1735203846; 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=zcSCy5IEhPo4izAQkjpZl0PDag3eVhrytTuA1E/L938=; b=bKcgJgpzIYuq3G8F5xnJh6QLWPamug++te++R5g+Bp3Qvk0atdpLdMpcy0anIEECMN65yc VYmJKuivD77WjiO9JUxxzRTadj0ftrkKPo+k8R2EfzSbm+GxaK+BaZGVXGVT/ID7CX0HM3 GgpAED2mBkIDIJ++TW4K/rE33vP02R0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1735203846; a=rsa-sha256; cv=none; b=1CboEnZIS2EdHvcBiyOShf8Ly+OGze/sTAnqGYwfgr9vKL1ad1ysVFcnxPGIkcyaqn2yiH UkdNCUYmKObmpdj/5GW0cfBRGo+xcD9ZmLZMoRghkGkoOlIBi0YtoZaMAZYS3R7d1pBKnd fyfg/SD8RM1jU7FqiAajGiAOoyARJ/4= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=KW3CdHF6; spf=pass (imf20.hostedemail.com: domain of gmonaco@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=gmonaco@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1735203864; 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=zcSCy5IEhPo4izAQkjpZl0PDag3eVhrytTuA1E/L938=; b=KW3CdHF6tL2xLNCifzOSoP1ozCc9WiofXJN1Z82RJV4OMMI2QuotCTMLbBAf88FyMpp9F7 69BfebvcO/6JeIA0X0K1sWP9VrkZPbbhjA7SIp6IMjX/oF8BSF3kHc3OnYq3N8FxXrWOJV fHArYfNaANjrh3/OeNARf7adBTVnQWY= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-5-14QmCfF7Oa6wR-GF3bVtvQ-1; Thu, 26 Dec 2024 04:04:23 -0500 X-MC-Unique: 14QmCfF7Oa6wR-GF3bVtvQ-1 X-Mimecast-MFC-AGG-ID: 14QmCfF7Oa6wR-GF3bVtvQ Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-4361b090d23so36440205e9.0 for ; Thu, 26 Dec 2024 01:04:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735203862; x=1735808662; 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=zcSCy5IEhPo4izAQkjpZl0PDag3eVhrytTuA1E/L938=; b=aMaC45mMGeSRArljaOTqSZB6m9whHoZuXSNUclHhnv3BIAMhivr3HQ/rM/o+vUo9Za vV0r5DhyS0LfaPs2Glsid3SNANj9iFAFhYNl4TqthCXn9A1boNUnh8D5h6l1Y09CHBDf 6bsB4PNNrc6vEiCAHwuJftavXLvYtjNRagV7XLCMW9AqDXnu9SqQ9OMoZcfJ6VpRXKfp r0tsfn+UzidBzXh0/dWKum0EcW71tZSOC5fBiHk2MAheGRjkTqO+pSwpp4EwdzEm/8Qu S7prR4FRd0dDf5pPVCKZmJZlFUGDSjFZeUmwM/LCzbt9oQIaZWKzn2P9eveV6d/6NX2A 36Ug== X-Forwarded-Encrypted: i=1; AJvYcCXQsW/p2KfDSogk3+WoNdie83bxwV2mqa/3D09GDhx8PjaAhMRLQLV+kz8kzsl0CK9CydnHwS3E4w==@kvack.org X-Gm-Message-State: AOJu0Yx1LGfzi1b3T5HdEwFPXspSQsU7RnlgCiBZrQ455i01OKe/IiPs OJYBX2HQZDP7zFEiXHXcsS83jTaqpdJe4TA2dT/nOpTGY47OkTOIJDPsWCXOomcV7pF+Xkm+FKP kWPSVSGsY9F0vozao7FL+fIHO82bN2qYlhzOpvWz/NH9flnXp X-Gm-Gg: ASbGncvZwVwjzdW2cYSVBlarWFDyMz5KI1DZA4YCn2xY1500HSi1SW53z0SMReDo15K CPwbDyMQfRAISme+Hi96PdZTrazH71b3mu/l0OaYeYFnKmU5gFjLuQCBa71GLmyBTCN+oEaBm3y 3oS2A1GFQWQTwLI9LrlljeRxRvN6sxu8tdmfwOICgPdRsXMn7bJNKO9svH0Y8uNQBQrFnymikwy iuQ2Llm0cVcU3iWV3iOzlnXUe7RStxvAnRPDT8iyP283ixOFSXOXRJZEQ3WtdnkFvJxZT1eCAiu 4nKpyJfoFg== X-Received: by 2002:a05:600c:4509:b0:436:1c04:aa8e with SMTP id 5b1f17b1804b1-4366864676emr199566505e9.16.1735203862371; Thu, 26 Dec 2024 01:04:22 -0800 (PST) X-Google-Smtp-Source: AGHT+IHjvxlaI/4f32BW7JJYstlUZCLypZbNhrZnM3gA1+pwoTO5ztebx1wpyLWDfO860QmndZRGdA== X-Received: by 2002:a05:600c:4509:b0:436:1c04:aa8e with SMTP id 5b1f17b1804b1-4366864676emr199566165e9.16.1735203861915; Thu, 26 Dec 2024 01:04:21 -0800 (PST) Received: from gmonaco-thinkpadt14gen3.rmtit.csb ([195.174.134.200]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a1c832e69sm18824058f8f.35.2024.12.26.01.04.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Dec 2024 01:04:21 -0800 (PST) Message-ID: <83fa755bad5e607cf242cacccb58a4ea2490b8a0.camel@redhat.com> Subject: Re: [PATCH v3 3/3] rseq/selftests: Add test for mm_cid compaction From: Gabriele Monaco To: Mathieu Desnoyers , Peter Zijlstra , Ingo Molnar , linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Juri Lelli , Shuah Khan Date: Thu, 26 Dec 2024 10:04:20 +0100 In-Reply-To: <6c159869-8f01-4aa5-9df1-7a0d6e3c23b7@efficios.com> References: <20241216130909.240042-1-gmonaco@redhat.com> <20241216130909.240042-4-gmonaco@redhat.com> <6c159869-8f01-4aa5-9df1-7a0d6e3c23b7@efficios.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.2 (3.54.2-1.fc41) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: lyxy5ZSY8dkxeO4ZacE8-eJ3frF9Q8dkD2yazgH8vp0_1735203862 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: B92FD1C0003 X-Stat-Signature: ew61eibdifg4uyqreicneh7zf1kxm3nj X-Rspam-User: X-HE-Tag: 1735203822-877822 X-HE-Meta: U2FsdGVkX1+U3rYZJmu7IFuJzU9RJdaYUrp+P8JA0gBog2Kf0vtHl3isnakIXIfUqugl4HCQcZVn3AUATZsS2g0B5xl4WpKU93oZSAd6zh1fUC03nu7lVE2soF2a5p0aEGj+hUYjiycXR5mVeb5vcEnrUSF6Xdm8UYDf3d8c9qqPPtj+R6qeYRq8HFZPQ9oU64qXrvRQTBUH5qv0l+rVlrMlSTn/xCPkTx8fYeSVMq1aQd1IW1HuAOc0UknezQaZ6n82m9Lr5CpdNl3orhPpweh826UvGMxvPc+1cSg9BRkllaWHbFWlx/w7LTDj6gPuWiifmaqvLMzJZyaLq14Fn3ROiueXj563fW1YDzBO51JrYe1QUhS2+w/Uw+8jg8PfJw0KJ79QzbIz9JdQW6JTolKBQPLgH9ct3c39GoRBssiXwBftaKZV0kdpoHOQgM/iIHzqcUWxR8OHSt9Mo3JoSWRtyaGqkqLY+EyjFzY1BEsveN7aV6WpLTCk25lpYEclQUkSl2LQ78RLaOtkh5L+wAH4wyh/P2gTt7+JAFFM6bdhjUsDYAHeUdKNdZFhBhy1uzglN38cmEtq7WgbMjdZCG2mJ9DlsGLHp5mH9uzSHtUPXrTzoNehq+7xkDP0OLGQUBtUA0mzZv5S/LG2xrn9g+jaz6MN6owePtRdPMF2RVt9xxRbjA7aRleUJcZUSo2NATLawf1JmhFzHPSU5ReNENIl3hnDDG/58Bwggh/OtjoM3VBdIAD4NOCZCI+TZL/duSffG4aQ2pLAD+e+ehyudCiodyaGuRGGdhyfD9KDDcA5Wleu6rure3yV9sGO1uvKAXUTInfwMZ0LbVURwjJnNXH7An2s1q+GPkrkWnYe2ZDrbbo4dX/VSzSB84CNMy5gMB7pbFmE3SpJp8s8p2DWhH8wKJJWVFBqI18U/LhHqcHJZaCyi7cXGMdAaQs3Gla6d4LO0preOBmBX7Da6YU 85HkvcEb L+eBMR5G6Vqouy3kDglOtz7fzqcw5vCYk+2hCj7Ko3mMHq+XwnQAEDwD/xkzrDuRJmiiJ5vi2a9hHOWKA0a1t+62tWhyxV3+0epfsNEmJoNjYx/8b2QnzgLhEzftRgOB+/OfdStbzOMQ5lFqveNk79UnkQBg/kYAeA0tM86hE1aDoMzVPa+VUgnWs1/MjQe5q16887/aFy39oe+wSPJ/nbKMipyrWuDPUMa5Tce41jVL7RvXwf78kuI91IfXDSwCpztj07UsYyzdxrFKJ4ugMHoFIWuHVVI1mDnAECSiXn/KwHVSlMVGuoGRY9q0WVGqvIEsynRoNSflc54TOb5lOCnpqqosmbjxAc+reuOPVBVBPsqf84dxZDVEJ07lrPp/lW3lJ 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 Tue, 2024-12-24 at 11:20 -0500, Mathieu Desnoyers wrote: > On 2024-12-16 08:09, Gabriele Monaco wrote: > > A task in the kernel (task_mm_cid_work) runs somewhat periodically > > to > > compact the mm_cid for each process, this test tries to validate > > that > > it runs correctly and timely. > >=20 > > + if (curr_mm_cid =3D=3D 0) { > > + printf_verbose( > > + "mm_cids successfully compacted, exiting\n"); > > + pthread_exit(NULL); > > + } > > + usleep(RUNNER_PERIOD); > > + } > > + assert(false); >=20 > I suspect we'd want an explicit error message here > with an abort() rather than an assertion which can be > compiled-out with -DNDEBUG. >=20 > > + } > > + printf_verbose("cpu%d has %d and is going to terminate\n", > > + =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sched_getcpu(), curr_mm_cid); > > + pthread_exit(NULL); > > +} > > + > > +void test_mm_cid_compaction(void) >=20 > This function should return its error to the caller > rather than assert. >=20 > > +{ > > + cpu_set_t affinity; > > + int i, j, ret, num_threads; > > + pthread_t *tinfo; > > + pthread_mutex_t *token; > > + struct thread_args *args; > > + > > + sched_getaffinity(0, sizeof(affinity), &affinity); > > + num_threads =3D CPU_COUNT(&affinity); > > + tinfo =3D calloc(num_threads, sizeof(*tinfo)); > > + if (!tinfo) { > > + fprintf(stderr, "Error: failed to allocate tinfo(%d): %s\n", > > + errno, strerror(errno)); > > + assert(ret =3D=3D 0); > > + } > > + args =3D calloc(num_threads, sizeof(*args)); > > + if (!args) { > > + fprintf(stderr, "Error: failed to allocate args(%d): %s\n", > > + errno, strerror(errno)); > > + assert(ret =3D=3D 0); > > + } > > + token =3D calloc(num_threads, sizeof(*token)); > > + if (!token) { > > + fprintf(stderr, "Error: failed to allocate token(%d): %s\n", > > + errno, strerror(errno)); > > + assert(ret =3D=3D 0); > > + } > > + if (num_threads =3D=3D 1) { > > + printf_verbose( > > + "Running on a single cpu, cannot test anything\n"); > > + return; >=20 > This should return a value telling the caller that > the test is skipped (not an error per se). >=20 Thanks for the review! I'm not sure how to properly handle these, but it seems to me the cleanest way is to use ksft_* functions to report failures and skipped tests. Other tests in rseq don't use the library but it doesn't seem a big deal if just one test is using it, for now. It gets a bit complicated to return values since we are exiting from the main thread (sure we could join the remaining /winning/ thread but we would end up with 2 threads running). The ksft_* functions solve this quite nicely using exit codes, though. > > + } > > + pthread_mutex_init(token, NULL); > > + /* The main thread runs on CPU0 */ > > + for (i =3D 0, j =3D 0; i < CPU_SETSIZE && j < num_threads; i++) { > > + if (CPU_ISSET(i, &affinity)) { >=20 > We can save an indent level here by moving this > in the for () condition: >=20 > =C2=A0for (i =3D 0, j =3D 0; i < CPU_SETSIZE && > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CPU_ISSET(i, &affinity) && j < num_threads= ; i++) { >=20 Well, if we assume the affinity mask is contiguous, which is likely but not always true. A typical setup with isolated CPUs have one housekeeping core per NUMA node, let's say 0,32,64,96 out of 127 cpus, the test would run only on cpu 0 in that case. > > + args[j].num_cpus =3D num_threads; > > + args[j].tinfo =3D tinfo; > > + args[j].token =3D token; > > + args[j].cpu =3D i; > > + args[j].args_head =3D args; > > + if (!j) { > > + /* The first thread is the main one */ > > + tinfo[0] =3D pthread_self(); > > + ++j; > > + continue; > > + } > > + ret =3D pthread_create(&tinfo[j], NULL, thread_runner, > > + =C2=A0=C2=A0=C2=A0=C2=A0 &args[j]); > > + if (ret) { > > + fprintf(stderr, > > + "Error: failed to create thread(%d): %s\n", > > + ret, strerror(ret)); > > + assert(ret =3D=3D 0); > > + } > > + ++j; > > + } > > + } > > + printf_verbose("Started %d threads\n", num_threads); >=20 > I think there is a missing rendez-vous point here. Assuming a > sufficiently long unexpected delay (think of a guest VM VCPU > preempted for a long time), the new leader can start poking > into args and other thread's info while we are still creating > threads here. >=20 Yeah, good point, I'm assuming all threads are ready by the time we are done waiting but that's not bulletproof. I'll add a barrier. Thanks again for the comments, I'll prepare a V4. Gabriele