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 2CD7C43209; Thu, 26 Oct 2023 16:59:56 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EE5F542830; Thu, 26 Oct 2023 16:59:55 +0200 (CEST) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 2979C40E54 for ; Thu, 26 Oct 2023 16:59:54 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 049BD205C3; Thu, 26 Oct 2023 16:59:54 +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:59:51 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9EF9D@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9EF9C@smartserver.smartshare.dk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH v3 0/2] allow creating thread with real-time priority Thread-Index: AdoIGQfEBT2V8C0qSFSWPtpNUVinOQAAR3YAAACGWiA= References: <20231024125416.798897-1-thomas@monjalon.net> <2434867.jE0xQCEvom@thomas> <98CBD80474FA8B44BF855DF32C47DC35E9EF9B@smartserver.smartshare.dk> <5410427.Sb9uPGUboI@thomas> <98CBD80474FA8B44BF855DF32C47DC35E9EF9C@smartserver.smartshare.dk> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Thomas Monjalon" , "David Marchand" Cc: , , 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: Morten Br=F8rup [mailto:mb@smartsharesystems.com] > Sent: Thursday, 26 October 2023 16.50 >=20 > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > Sent: Thursday, 26 October 2023 16.31 > > > > 26/10/2023 16:08, Morten Br=F8rup: > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > > Sent: Thursday, 26 October 2023 16.05 > > > > > > > > 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.) > > > > > > > > 10 ms looks like an eternity. > > > > > > 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. >=20 > It seems David came to our rescue here! >=20 > I have just tried running our test again with prctl(PR_SET_TIMERSLACK) = of 1 > ns, and the nanosleep(1 ns) delay dropped from ca. 50 us to ca. 2.5 = us. >=20 > The timeout parameter to epoll_wait() is in milliseconds, which is = useless for > low-latency. > Perhaps real-time threads can be used with epoll() combined with = timerfd for > nanosecond resolution timeout. Or epoll_pwait2(), which has nanosecond resolution timeout. Unfortunately, rte_epoll_wait() is not an experimental API anymore, so = we cannot change its timeout parameter from milliseconds to micro- or = nanoseconds. We would have to introduce a new API for this. >=20 > > 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) >=20 > Only the application developer knows how much delay is acceptable. = Which is > why I mentioned that the new yield functions should document the = delay. >=20 > > > > > > I will try. > > > > (Anyway I did a mistake when sending v4) > > > > I've sent a trial with 1 ms. > >