From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id AA06B43209; Thu, 26 Oct 2023 16:04:46 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8CBE8402DE; Thu, 26 Oct 2023 16:04:46 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 00562402CF for <dev@dpdk.org>; Thu, 26 Oct 2023 16:04:44 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.nyi.internal (Postfix) with ESMTP id 932075C0234; Thu, 26 Oct 2023 10:04:44 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 26 Oct 2023 10:04:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1698329084; x=1698415484; bh=fXEzWnTWQtvXJhX7WYww5YYTX0Sq6oQYVjg Tzt/gazs=; b=GtUKOB5xfp5AvSNFvrlsAsQtXNf0dC5O3K3l+hjX2rM8NH4PLBt +/sgmTxmicnJ511qJ9kKAMhir47gQ8wGFtdjL0NsseReMfa6Hj1pHgYwEZgxMrSi 8AQSd8fj4fu8YsK07VFIVOt6u3S2JFZ8UyvehfecQb5qMn7AbC4GgkbWLmXM9t5n RN/gHs+cDhnPkuFL49NS5BsajFU9pWJP6SRYttkG0bzD5OX3iswI2377/SsX5uLH XHdUs5v7qJkqjNaITGcRpPA6FK33T7Ue1CO/3BjcvO9wk8jlNTECnBQ6uOqA6G3V mTkWXAiDBIOh+xqG1Mz/vof/1usq95RbcJQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1698329084; x=1698415484; bh=fXEzWnTWQtvXJhX7WYww5YYTX0Sq6oQYVjg Tzt/gazs=; b=qjP9NOyK4q6ure/uN0Nw3O6smHHc8d6P4DM34IrU/hfqO8wyDfO KjQcoO/OqI+ZBn+eNQBv/oSxciyRge9VVCiTPvlIXiB9UMTTpCydw5S8cCFwfsDt pKyKvS9f0z3A/acdSwteXORmAZQD7AYFKL7yqyDK3FF351JH3ZXtU78vi6M8P2ss 05VhZQGB5MbrUTdKlkKtP4oK8KI/iokzx15+g5NAnvJYURM704pRt6P18RMAChQQ DDyxx16dB9YqDnjhSPBR4QEDDpRoi03iB0s2R7oAUSo7j1ehuLWdu0PU+qNwmG0k yrHazlHQ9FYyYIh5MwEQKa993pUN4/u/fgg== X-ME-Sender: <xms:-3E6ZfbV8Bz8drK9Qfnxsbn9qcvHET0o4f8hRbM3SIGfWUq_0MGz0A> <xme:-3E6ZeY5hI0zXe2ZlWSg-2II3EOo1Axya0avDRSnVdrho6xQeQky2ke0zK_lKL2Xh mkpdCzAWNvq2c3SBQ> X-ME-Received: <xmr:-3E6ZR-judi5fwL67oadCmKi5oVP8rs_9zGCdbjRXUMbAsTlFcOBvq_CKjAeIP8GlIbhd3I5Y60_brKf7hvoSlsvRQ> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrledvgdejvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtqhertddttddunecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepfefhjeeluedvvedtuddtuedtvefhieejtefhffeujefhteduudev tdektdeikeffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: <xmx:_HE6ZVq6D5cjqgQgY2Ffq2Q2CRj6Oty4QhGriGu_gUCatjVowiWXrA> <xmx:_HE6Zar4WoYussgkjvpdf9fnWPmrmZwd2UCbCZ9AMHdQ6tJ3Y51Hxw> <xmx:_HE6ZbQ4wxm1EJvHIqe_41Dwd1guoM99hZaoG2YuvENwZAeCjpaLOQ> <xmx:_HE6ZdWADnZOE_Q4i68Uo-kQKn3OvjipMqiov4dNXdGm7SIkVtIdXA> Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 26 Oct 2023 10:04:43 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: Morten =?ISO-8859-1?Q?Br=F8rup?= <mb@smartsharesystems.com> Cc: stephen@networkplumber.org, bruce.richardson@intel.com, dev@dpdk.org, David Marchand <david.marchand@redhat.com> Subject: Re: [PATCH v3 0/2] allow creating thread with real-time priority Date: Thu, 26 Oct 2023 16:04:41 +0200 Message-ID: <2434867.jE0xQCEvom@thomas> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9EF9A@smartserver.smartshare.dk> References: <20231024125416.798897-1-thomas@monjalon.net> <98CBD80474FA8B44BF855DF32C47DC35E9EF99@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9EF9A@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org 26/10/2023 15:57, Morten Br=F8rup: > > From: Morten Br=F8rup [mailto:mb@smartsharesystems.com] > > Sent: Thursday, 26 October 2023 15.45 > >=20 > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > Sent: Thursday, 26 October 2023 15.37 > > > > > > 25/10/2023 18:31, Thomas Monjalon: > > > > Real-time thread priority was been forbidden on Unix > > > > because of problems they can cause. > > > > Warnings and helpers are added to avoid deadlocks, > > > > so real-time can be allowed on all systems. > > > > > > Unit test is failing: > > > DPDK:fast-tests / threads_autotest TIMEOUT 600.01 s > > > > > > It is seen in only 1 target (maybe the failure occurence is random): > > > Debian 11 (Buster) (ARM) | PASS > > > Fedora 37 (ARM) | PASS > > > CentOS Stream 9 (ARM) | FAIL > > > Fedora 38 (ARM) | PASS > > > Fedora 38 (ARM Clang) | PASS > > > Ubuntu 20.04 (ARM) | PASS > > > > > > I need to send a v4 with new implementation and better comments. > > > The Unix sleep will be upgraded from 1 ns to 1 us in case it makes a > > > difference. > >=20 > > It will not make a difference. The kernel will go through the sleeping = steps, > > then wake up again and see the real-time thread is ready to run, and th= en > > immediately schedule it. > >=20 > > For testing purposes, consider sleeping 10 milliseconds or something > > significant like that. >=20 > A bit more details... >=20 > In our recent tests, nanosleep() itself took around 50 us. So you need to= sleep longer than that for your thread not to be runnable when the nanosle= ep() wakes up again, because 50 us has already passed in "nanosleep overhea= d". > 10 milliseconds provides plenty of margin, and corresponds to 10 jiffies = on a 1000 Hz kernel. (I don't know if it makes any difference for the kerne= l scheduler if the timer crosses a jiffy border or not.) 10 ms looks like an eternity. I will try. (Anyway I did a mistake when sending v4)