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 4CC2B43209; Thu, 26 Oct 2023 16:08:06 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 09431402CF; Thu, 26 Oct 2023 16:08:06 +0200 (CEST) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 31DDB402B5 for ; Thu, 26 Oct 2023 16:08:04 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 0A8EE205C3; Thu, 26 Oct 2023 16:08:04 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH v3 0/2] allow creating thread with real-time priority X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 26 Oct 2023 16:08:02 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9EF9B@smartserver.smartshare.dk> In-Reply-To: <2434867.jE0xQCEvom@thomas> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH v3 0/2] allow creating thread with real-time priority Thread-Index: AdoIFWEW2UcJ3J8tTfi2hk/fUe6msgAABzmQ References: <20231024125416.798897-1-thomas@monjalon.net> <98CBD80474FA8B44BF855DF32C47DC35E9EF99@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9EF9A@smartserver.smartshare.dk> <2434867.jE0xQCEvom@thomas> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Thomas Monjalon" Cc: , , , "David Marchand" 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 > 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 = 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. > > > > > > 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 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 = need to > sleep longer than that for your thread not to be runnable when the = nanosleep() > wakes up again, because 50 us has already passed in "nanosleep = overhead". > > 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 = kernel > scheduler if the timer crosses a jiffy border or not.) >=20 > 10 ms looks like an eternity. Agree. It is only for functional testing, not for production! > I will try. > (Anyway I did a mistake when sending v4) >=20 >=20