From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id BBFC643209; Thu, 26 Oct 2023 16:30:56 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A0CAC402CF; Thu, 26 Oct 2023 16:30:56 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 1D2D6402B5 for ; Thu, 26 Oct 2023 16:30:55 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6FDCC5C0037; Thu, 26 Oct 2023 10:30:54 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 26 Oct 2023 10:30:54 -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= 1698330654; x=1698417054; bh=yEFtBFR0IarzyaMAfHjl0bV1WXdzEHepdWp WsruYlms=; b=V5IsEufqYsb/kouOPPWG0yMc+IzAVOqvrCaH4XNGIfOGCHshByS yPh/HsdB/OkE6GL3mQkiagUSChitCrESK+o8MoBVJ5kSgFtc6NoVZE4kjBJdg+0Y IbEEFa7bJWiDPR3DOSp7B7vCyhN7A5JLcJ0OhJfPUGXnuP/CS2vRDqg0/E/nRsMA ef3Ees3wheQ1jjsZfqjUTevczlHQblboemrgS3ZArA6fRTrlNH2nioUYuiLwf8eJ EdPxgm0M+rCzqztfe29WNFX5aqMeV+G8u28OOzkBMuQDRt4BD7jTu8Rdx8/JSFzB a3M47ezJ9UEcYRJZZCu6zw0WxVQNAZZzagg== 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= 1698330654; x=1698417054; bh=yEFtBFR0IarzyaMAfHjl0bV1WXdzEHepdWp WsruYlms=; b=OFWVQJHINTJnb/yi9hX7Qq/EQi6MREwrC9mxlVkXqqNXBzMJlRC ja1z2Z4Cna5KcLBGWxUh4CGyPpcPPCeGXF+Wp5hCIz6IFzBT/eaFabYZ0manXAxI S+M7BYnlFnnyAqQQi+3qAB1rK4FHhHtoxxTV7oumgzhAA2JIadaNcnnlA1Tld/RC 7wQEyUBeBY3+oCF5U2c/Xc2bsbCxa4qf+NYfMdG8B6iAtIXOxKADhf4iL9NuimhR potvljR7thKVgwr8Oz5HnXXme31mYTNJStB1PW3I8oEQ+yWQnhfU2lHCnW9Z23K/ HDuEx7LECiJpnmWbx/BF+zQupHruklwcRhg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrledvgdejkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtqhertddttddunecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepfefhjeeluedvvedtuddtuedtvefhieejtefhffeujefhteduudev tdektdeikeffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 26 Oct 2023 10:30:52 -0400 (EDT) From: Thomas Monjalon To: Morten =?ISO-8859-1?Q?Br=F8rup?= Cc: dev@dpdk.org, stephen@networkplumber.org, bruce.richardson@intel.com, David Marchand Subject: Re: [PATCH v3 0/2] allow creating thread with real-time priority Date: Thu, 26 Oct 2023 16:30:50 +0200 Message-ID: <5410427.Sb9uPGUboI@thomas> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9EF9B@smartserver.smartshare.dk> References: <20231024125416.798897-1-thomas@monjalon.net> <2434867.jE0xQCEvom@thomas> <98CBD80474FA8B44BF855DF32C47DC35E9EF9B@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 26/10/2023 16:08, Morten Br=F8rup: > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > Sent: Thursday, 26 October 2023 16.05 > >=20 > > 26/10/2023 15:57, Morten Br=F8rup: > > > > From: Morten Br=F8rup [mailto:mb@smartsharesystems.com] > > > > Sent: Thursday, 26 October 2023 15.45 > > > > > > > > > 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 rando= m): > > > > > 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 make= s a > > > > > difference. > > > > > > > > It will not make a difference. The kernel will go through the sleep= ing > > steps, > > > > then wake up again and see the real-time thread is ready to run, an= d then > > > > immediately schedule it. > > > > > > > > For testing purposes, consider sleeping 10 milliseconds or something > > > > significant like that. > > > > > > A bit more details... > > > > > > In our recent tests, nanosleep() itself took around 50 us. So you nee= d to > > sleep longer than that for your thread not to be runnable when the nano= sleep() > > wakes up again, because 50 us has already passed in "nanosleep overhead= ". > > > 10 milliseconds provides plenty of margin, and corresponds to 10 jiff= ies on > > a 1000 Hz kernel. (I don't know if it makes any difference for the kern= el > > scheduler if the timer crosses a jiffy border or not.) > >=20 > > 10 ms looks like an eternity. >=20 > Agree. It is only for functional testing, not for production! Realtime thread won't make any sense if we have to insert a long sleep. We need to find a good sleep value or give up with real-time threads. (note I'm not sure how much it is useful) > > I will try. > > (Anyway I did a mistake when sending v4) I've sent a trial with 1 ms.