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 21DD6C25B6B for ; Thu, 26 Oct 2023 19:20:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 82A2D8D002F; Thu, 26 Oct 2023 15:20:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DA7C8D0001; Thu, 26 Oct 2023 15:20:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A2B48D002F; Thu, 26 Oct 2023 15:20:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 5C3F48D0001 for ; Thu, 26 Oct 2023 15:20:35 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 24A7C1A0BAB for ; Thu, 26 Oct 2023 19:20:35 +0000 (UTC) X-FDA: 81388579230.21.52EF96D Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf14.hostedemail.com (Postfix) with ESMTP id C2EAB10001D for ; Thu, 26 Oct 2023 19:20:32 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf14.hostedemail.com: domain of "SRS0=xBQK=GI=goodmis.org=rostedt@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=xBQK=GI=goodmis.org=rostedt@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698348033; 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; bh=6Z+djTTZMrrcesa9yxXUiL4woVh3tYkVEzBKHHLlybY=; b=0liK+sufEgOPDmijNBAF0t8G3uJnyXL2AqaEMocsd0VFwzvIlx241MAuWaS1WJ+zY5OCfi BIC6YLmf5Yu4ROu22op2wtcVkvufujqYHZSXCwJdorXlN08IT11XHftqHCmOHF9AUqwu3c inFJ0sojCL45yHt8i0SC+ot4qvlTsBA= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf14.hostedemail.com: domain of "SRS0=xBQK=GI=goodmis.org=rostedt@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=xBQK=GI=goodmis.org=rostedt@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698348033; a=rsa-sha256; cv=none; b=QlKDlGXit9KdAsoMs7wGwTjIyIohK6OehOc55foLJiI4wQ1IJVQBXv94dE3rQ8bu9t5dzI gcvHKwPlh1KOlJcDOD17j13eI8FUadnLU6UM5z3ShwWgACGo0R+rCEISeGtaVO85/Hg9Bl PXMy28fcc0TqC4tT008uWtoihbJeTjs= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id CF51CCE3FCB; Thu, 26 Oct 2023 19:20:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 91384C433C8; Thu, 26 Oct 2023 19:20:24 +0000 (UTC) Date: Thu, 26 Oct 2023 15:20:22 -0400 From: Steven Rostedt To: Mathieu Desnoyers Cc: Peter Zijlstra , LKML , Thomas Gleixner , Ankur Arora , Linus Torvalds , linux-mm@kvack.org, x86@kernel.org, akpm@linux-foundation.org, luto@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, willy@infradead.org, mgorman@suse.de, jon.grimm@amd.com, bharata@amd.com, raghavendra.kt@amd.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com, jgross@suse.com, andrew.cooper3@citrix.com, Joel Fernandes , Youssef Esmat , Vineeth Pillai , Suleiman Souhlal , Ingo Molnar , Daniel Bristot de Oliveira Subject: Re: [POC][RFC][PATCH v2] sched: Extended Scheduler Time Slice Message-ID: <20231026152022.668ca0f3@gandalf.local.home> In-Reply-To: References: <20231025235413.597287e1@gandalf.local.home> <20231026105944.GJ33965@noisy.programming.kicks-ass.net> <20231026071413.4ed47b0e@gandalf.local.home> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: abgrpwdacony1q536wyfsrkpd3tfzsfy X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: C2EAB10001D X-HE-Tag: 1698348032-905662 X-HE-Meta: U2FsdGVkX1+EJyt0Bmi2uYNW7U2FQrw5C56b51E5ALbEpj3SMRbWWSBWRWv44GlVhn2PLYgGT6F4kNysuWw7R7k20SaBZwhA1C2GykneGwTy521eMvAtVVV8rvt44EjnmTnk1+PC82XVu4rEs1/DvIJ6GlKjdyRQ7R6pxLKWVzFTtAzjd5WWZhbMkEkSdqtxbl2vsPGbg+ViHtr09wNqV0MrEUl3j9MNtJU+sNwyNCddtlnrDBhGffuO8jh43KNU+fJ65vsBxLAZhvuM1cmHmVj+S8w1SvDgeTOvQ/hBKAYYvaqGE2zv8jMJ0iJuiYlcrwfC5AYCgOYyhDYb3S5f56SQtV1kg/FwTz+9ieotGNSqV6quB336RJay3j96F5Q3K2ciuDuDokMOdICKEymlYAuOVbMWiGfCrt2dOYKHryWTFCEKTLFckdqwvoxgkhz/D+dcLE5C8QCjrLM7E35gYhN/T5nW1nOa/mqIBDiYCFGP9U2Ed2cs/FPycKC7U2G2TT8KVWxCi+l5RxbAxGZ66rpk+VLl0+m2M5g2NGlDiQ/B7hvb+ydoP/vW/Zle12UlkT1AjlyAZ5eWiSfZ6ssFG3+Q3Nho7J8oF+rm8UcZqR73yxs74R26MmZbRIrO2QsqFBT6leaJjoz3g2MAsZ2AX5JLgVmM+1Dtk3lbgC7ctTxaULdYJvA+zKHvQzxFw4DizjWauYNQv7h13qk8L94zPlUCzabSiOb9+nJbN+kTEn9tpgO6rtofq8b5jKE8QLvzDIeZ2QA/LdIZJbu+09yDykb81bzogcX2HVd6o8PxG7zXW1dwFh/G7YbXvcAm2swipJaziuakCBcTQcA4QyDFUPYC5R54/+h8n9O6weG9k+ErI/TH/bxwj02DuqsSW3/T1sKqJQRUbqPYGXHWLpYCW80AnKdgDw3+bi9D8dwnrV7VmWtF1o/Rmuua+STIvFtms0kQm35YNn1LIza7E3v X2BWCK6k bXYPoZ2a+qV2zOa9qmr2Z/cCKG1KpK1BuC5gKF6HIKmry/ionj2FZ6or2zevBzAYRIIXEBLRlbo1KW4QSSmYDHldtEab3WvtyDxJ8wHZZQG5JCYga/2f+ZcgwvIpzmsY8vKr8cKzbN4TTM/W8EWajV5S3q+rS6+Jb46PP20LyQEx/T2rA6TLtD8nU2VxIp4NZ9IFZuIJIQ9ljWXyiLK2fcXo/ez0Dxct0eESg54JoMxbELJvbXw7sXgHGMSQ0BhrrLuVt1xPGVWJw2givLbnEvY3egAoUscqANqzbIdOrnxM8jtluYlHcfBPhAQ== 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, 26 Oct 2023 14:36:36 -0400 Mathieu Desnoyers wrote: > > static inline unsigned long > > xchg(volatile unsigned *ptr, unsigned new) > > { > > unsigned ret =3D new; > >=20 > > asm volatile("xchg %b0,%1" =20 >=20 > which has an implicit lock prefix (xchg with a memory operand is a=20 > special-case): >=20 > Quoting Intel manual: >=20 > "If a memory operand is referenced, the processor=E2=80=99s locking proto= col is=20 > automatically implemented for the duration of the exchange operation,=20 > regardless of the presence or absence of the LOCK prefix or of the value= =20 > of the IOPL. (See the LOCK prefix description in this chapter for more=20 > information on the locking protocol.)" >=20 Bah. I learn something new every day :-p I thought xchg required specifying lock too. This means that cmpxchg is actually faster than xchg! It's been a long time since I had written assembly. What makes this interesting though, is that when I ran my tests originally, when my change was disabled, the xchg() code never executed, and it still showed a significant improvement. That is, even with adding xchg(), it still improved much more. But that's probably because the xchg() happens after releasing the lock and after that it goes into a loop waiting for another thread to make the update, which requires a lock cmpxchg(). Hence, the xchg() slowdown wasn't in a critical path of the test. Anyway, I changed the code to use: static inline unsigned clrbit(volatile unsigned *ptr) { unsigned ret; asm volatile("andb %b1,%0" : "+m" (*(volatile char *)ptr) : "iq" (0x2) : "memory"); ret =3D *ptr; *ptr =3D 0; return ret; } I just used andb as that's a locally atomic operation. I could also use bts (as Mathieu suggested to me on IRC). It doesn't matter as this is just example code and is not in production. How this is implemented is not an important part of the algorithm. Just that it can atomically clear the bit it sets without a race with the kernel setting the bit it sets. I could modify the code to put these bits in separate bytes as well. That's just an implementation detail we can work on later. I updated my test to have: static bool no_rseq; static void init_extend_map(void) { int ret; if (no_rseq) return; ret =3D rseq(&rseq_map, sizeof(rseq_map), 0, 0); perror("rseq"); printf("ret =3D %d (%zd) %p\n", ret, sizeof(rseq_map), &rseq_map); } static inline unsigned clrbit(volatile unsigned *ptr) { unsigned ret; asm volatile("andb %b1,%0" : "+m" (*(volatile char *)ptr) : "iq" (0x2) : "memory"); ret =3D *ptr; *ptr =3D 0; return ret; } static void extend(void) { if (no_rseq) return; rseq_map.cr_flags =3D 1; } static void unextend(void) { unsigned prev; if (no_rseq) return; prev =3D clrbit(&rseq_map.cr_flags); if (prev & 2) { tracefs_printf(NULL, "Yield!\n"); sched_yield(); } } where the tests with it disabled do not run the extend or unextend() code (as it makes sense to only perform that code with this feature, as that would be part of the overhead to implement it). Here's the results: With no_rseq =3D true, with 5 runs, which were basically all the same, but the best run was: Ran for 4260797 times Total wait time: 33.905306 And with no_rseq =3D false; Most runs were like: Ran for 5378845 times Total wait time: 32.253018 But the worse run was: Ran for 4991411 times Total wait time: 31.745662 But with that lower "wait time" it probably was preempted by a something else during that run, as the lower the "wait time" the better the result. -- Steve