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 AB3454320C; Thu, 26 Oct 2023 23:10:53 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 76BEC402C2; Thu, 26 Oct 2023 23:10:53 +0200 (CEST) Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) by mails.dpdk.org (Postfix) with ESMTP id 4DE7D402B7 for ; Thu, 26 Oct 2023 23:10:52 +0200 (CEST) Received: by mail-pf1-f177.google.com with SMTP id d2e1a72fcca58-6bd32d1a040so1351531b3a.3 for ; Thu, 26 Oct 2023 14:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1698354651; x=1698959451; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=L4RKff9IUIkC4CbUjLLpiIko1B3K5Ew80zIe2Z2odpE=; b=J/Y4FTlnHNmT6aRHpQbYDkrkWXLYB6Klg9xsIOWte5CxumTvysdxW4pUC5SL24Ra4q uc7xgELO2PCfonLZ2MQfFRSzoo6c3yRMceEjm/1uQNyFelMRDYVRXlMrm3xKC+JocAJj GH3UbwtlNN+wSh05hdxXYH+3stZ3WXvDg6f+90tj4QKntphf6y1zBusOM4xDCxwr8GJe kU2Fle8z9rHROYdYledkPl//ivyhVh4usShoy3HJMvSBKPfLyTuzB3yNDRimgBemB6MT XuXb7gJL1mI3y6siyDmVwrFXmXUUB4814yzGr8Vl7VHTlLZoy8bwfKkSQHXiMHAvDNIB ESDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698354651; x=1698959451; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=L4RKff9IUIkC4CbUjLLpiIko1B3K5Ew80zIe2Z2odpE=; b=v056gookPZyTkpdCmfrSqjCL1OVIOWE+XdCUgTqWXnt+db79Subm1mG5EdsQYdpPSm adFxVwd+Fx651K8YjPmGnitVNLjIqdLZXdqpNb8mqCNxsNxEFCXfTiQ+IqD7z7pcoEXJ uQIwyu4l+OR6aYy7KkIHTVKPP8pzvmgHbx8hAQCt1rzbv8vUAPalfeCih/kXA9aFi0ci C9wpWMZMGZrFIL4twiH3kjMzPM7jqt9Rw9/gOguYyHj5houscSrnaqDk4e3HjxMfozfy AZ4nqhuyLwYBD3ksV3L4PiUT3JVgSLbi3Xrf2tDI6cajo/mivD63Vsq5ThM1IIy3VQDr aFVw== X-Gm-Message-State: AOJu0Yw3GWlgNiTErEhuei80ntWg5PFdZ3KgKGWBG73oikeEXdABrzxX SCSEl/oQeK92UX0y1MbRcNaTYQ== X-Google-Smtp-Source: AGHT+IHSaBhzWsQZXOD6We3/NfzCVvufZB2tT4H0k9XV6RbKts+xTgGdcmlLIF9OM+0DYhLgHuzYSA== X-Received: by 2002:a05:6a21:7746:b0:153:7515:9919 with SMTP id bc6-20020a056a21774600b0015375159919mr1038306pzc.21.1698354651018; Thu, 26 Oct 2023 14:10:51 -0700 (PDT) Received: from hermes.local (204-195-126-68.wavecable.com. [204.195.126.68]) by smtp.gmail.com with ESMTPSA id gx1-20020a056a001e0100b006b65b0f903csm29313pfb.192.2023.10.26.14.10.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Oct 2023 14:10:50 -0700 (PDT) Date: Thu, 26 Oct 2023 14:10:48 -0700 From: Stephen Hemminger To: Thomas Monjalon Cc: Morten =?UTF-8?B?QnLDuHJ1cA==?= , dev@dpdk.org, bruce.richardson@intel.com, David Marchand Subject: Re: [PATCH v3 0/2] allow creating thread with real-time priority Message-ID: <20231026141048.29c2ff9e@hermes.local> In-Reply-To: <2655403.X9hSmTKtgW@thomas> References: <20231024125416.798897-1-thomas@monjalon.net> <98CBD80474FA8B44BF855DF32C47DC35E9EF9B@smartserver.smartshare.dk> <20231026092840.71f0772b@hermes.local> <2655403.X9hSmTKtgW@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Thu, 26 Oct 2023 21:55:24 +0200 Thomas Monjalon wrote: > > To be safe the sleep has to be longer than the system clock tick. > > Most systems are built today with HZ=250 but really should be using HZ=1000 > > on modern CPU's. > > If it has to be more than 1 ms, > we should mention it is a slow call > which may be skipped if the thread is already blocking on something else. A thread that is real time is not subject to timer slack. Therefore even 100ns would probably work fine. https://man7.org/linux/man-pages/man7/time.7.html High-resolution timers Before Linux 2.6.21, the accuracy of timer and sleep system calls (see below) was also limited by the size of the jiffy. Since Linux 2.6.21, Linux supports high-resolution timers (HRTs), optionally configurable via CONFIG_HIGH_RES_TIMERS. On a system that supports HRTs, the accuracy of sleep and timer system calls is no longer constrained by the jiffy, but instead can be as accurate as the hardware allows (microsecond accuracy is typical of modern hardware). You can determine whether high-resolution timers are supported by checking the resolution returned by a call to clock_getres(2) or looking at the "resolution" entries in /proc/timer_list. HRTs are not supported on all hardware architectures. (Support is provided on x86, ARM, and PowerPC, among others.) ... Timer slack Since Linux 2.6.28, it is possible to control the "timer slack" value for a thread. The timer slack is the length of time by which the kernel may delay the wake-up of certain system calls that block with a timeout. Permitting this delay allows the kernel to coalesce wake-up events, thus possibly reducing the number of system wake-ups and saving power. For more details, see the description of PR_SET_TIMERSLACK in prctl(2). ... https://man7.org/linux/man-pages/man2/prctl.2.html PR_SET_TIMERSLACK (since Linux 2.6.28) Each thread has two associated timer slack values: a "default" value, and a "current" value. This operation sets the "current" timer slack value for the calling thread. arg2 is an unsigned long value, then maximum "current" value is ULONG_MAX and the minimum "current" value is 1. If the nanosecond value supplied in arg2 is greater than zero, then the "current" value is set to this value. If arg2 is equal to zero, the "current" timer slack is reset to the thread's "default" timer slack value. The "current" timer slack is used by the kernel to group timer expirations for the calling thread that are close to one another; as a consequence, timer expirations for the thread may be up to the specified number of nanoseconds late (but will never expire early). Grouping timer expirations can help reduce system power consumption by minimizing CPU wake-ups. The timer expirations affected by timer slack are those set by select(2), pselect(2), poll(2), ppoll(2), epoll_wait(2), epoll_pwait(2), clock_nanosleep(2), nanosleep(2), and futex(2) (and thus the library functions implemented via futexes, including pthread_cond_timedwait(3), pthread_mutex_timedlock(3), pthread_rwlock_timedrdlock(3), pthread_rwlock_timedwrlock(3), and sem_timedwait(3)). Timer slack is not applied to threads that are scheduled under a real-time scheduling policy (see sched_setscheduler(2)). When a new thread is created, the two timer slack values are made the same as the "current" value of the creating thread. Thereafter, a thread can adjust its "current" timer slack value via PR_SET_TIMERSLACK. The "default" value can't be changed. The timer slack values of init (PID 1), the ancestor of all processes, are 50,000 nanoseconds (50 microseconds). The timer slack value is inherited by a child created via fork(2), and is preserved across execve(2). Since Linux 4.6, the "current" timer slack value of any process can be examined and changed via the file /proc/pid/timerslack_ns. See proc(5).