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 2696D43209;
	Thu, 26 Oct 2023 16:11:00 +0200 (CEST)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id A049440DDC;
	Thu, 26 Oct 2023 16:10:59 +0200 (CEST)
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by mails.dpdk.org (Postfix) with ESMTP id E0D8E402CF
 for <dev@dpdk.org>; Thu, 26 Oct 2023 16:10:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1698329457;
 h=from:from: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=K47RZTP8JRRPo25I5wWSTrIf9ceW4g2nApXo7TOTwJs=;
 b=Y7QXF+5LMJuzwRJDZ81h/rKUpKxhVwmfRgK0HrHt29fgyeZLfUahi6HqkTMkP7xvJH7BEJ
 NF3hPTBmiapv8mb+g6Km5lW0iE4wauR5iD4ilptbH9sE5TFglvhYXatsp9+HFdpn1iR22o
 P/ObYZ/rGJdd3kzF7I66Qv15luc3RbA=
Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com
 [209.85.208.199]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-241-fWWtg2rXMOmJuxwui6K1ow-1; Thu, 26 Oct 2023 10:10:56 -0400
X-MC-Unique: fWWtg2rXMOmJuxwui6K1ow-1
Received: by mail-lj1-f199.google.com with SMTP id
 38308e7fff4ca-2c503af866dso10246731fa.2
 for <dev@dpdk.org>; Thu, 26 Oct 2023 07:10:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1698329454; x=1698934254;
 h=content-transfer-encoding:cc:to:subject:message-id:date:from
 :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=K47RZTP8JRRPo25I5wWSTrIf9ceW4g2nApXo7TOTwJs=;
 b=u+R4U2SwbaBIu6BLWhNFannl5lqE+8rPZCz15HhvfrsmzUpqUtujOPj7Mi0kDcZ5Vr
 1Q1I17FFOq8x/qBvRLa1IxzvEEWWIhyjs8vVuEYJ8WB+m0uz6YBIhjC3Bb0WnIvXLKtN
 7rTx1GJ2xr3Y8JP+Maqz/sMt584bnJrXyodiB7kpjOgfTFQzYkEyQngPbnIapzMqigTX
 15z0UrVzdmUX0vOD9S7rxqr5TN1NpWqy8HL5HZgPMfyt94ES++hkpVZ7FSoYSM722GUL
 MqE7ZJfecswIND05bx9YnspgSedtQVdvdwZj1jrZGhms5PVSTZ3QhmyEDYYGaHTDclSh
 NDZA==
X-Gm-Message-State: AOJu0Yyk9EbndQeWiKsXgqy1z7qGbrMU7UW8aufJ1cb0d61vjvEA4hzs
 tY4YQWmaZO1TyN7RKq9BBA2lL6YHdoTAtXukY/FugUASI+CLwamevSKyoJw+6lzZ/gk48T3Dyvy
 jq/ekiKpGqzu9KKv3hh8=
X-Received: by 2002:a05:651c:2106:b0:2c5:2103:604b with SMTP id
 a6-20020a05651c210600b002c52103604bmr12758299ljq.2.1698329454636; 
 Thu, 26 Oct 2023 07:10:54 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IHPPWQPPTa1Jk2HJVACLUMseFzSxNZIpA/ruavhW/82tCoQAwkk02HzbYFcFPH32JT2LX0kzJf1kpeF5Wt2Dho=
X-Received: by 2002:a05:651c:2106:b0:2c5:2103:604b with SMTP id
 a6-20020a05651c210600b002c52103604bmr12758282ljq.2.1698329454316; Thu, 26 Oct
 2023 07:10:54 -0700 (PDT)
MIME-Version: 1.0
References: <20231024125416.798897-1-thomas@monjalon.net>
 <20231025163352.1076755-1-thomas@monjalon.net>
 <2170731.Icojqenx9y@thomas>
 <98CBD80474FA8B44BF855DF32C47DC35E9EF99@smartserver.smartshare.dk>
 <98CBD80474FA8B44BF855DF32C47DC35E9EF9A@smartserver.smartshare.dk>
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9EF9A@smartserver.smartshare.dk>
From: David Marchand <david.marchand@redhat.com>
Date: Thu, 26 Oct 2023 16:10:42 +0200
Message-ID: <CAJFAV8zScXz8_vXhELP40PmzkU1pavWomJv+B4crYwFgF4tMAQ@mail.gmail.com>
Subject: Re: [PATCH v3 0/2] allow creating thread with real-time priority
To: =?UTF-8?Q?Morten_Br=C3=B8rup?= <mb@smartsharesystems.com>
Cc: Thomas Monjalon <thomas@monjalon.net>, stephen@networkplumber.org, 
 bruce.richardson@intel.com, dev@dpdk.org
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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

On Thu, Oct 26, 2023 at 3:57=E2=80=AFPM Morten Br=C3=B8rup <mb@smartsharesy=
stems.com> wrote:
>
> > From: Morten Br=C3=B8rup [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 th=
en
> > 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 nanosle=
ep() wakes up again, because 50 us has already passed in "nanosleep overhea=
d".

You may want to read manual for prctl and look for PR_SET_TIMERSLACK.
https://github.com/openvswitch/ovs/commit/f62629a55894546ff043e8a116c3c57af=
f73c285

> 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.)



--=20
David Marchand