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 B8DF0A0032 for ; Fri, 24 Jun 2022 17:41:47 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 36DEA4069D; Fri, 24 Jun 2022 17:41:47 +0200 (CEST) Received: from smail.rz.tu-ilmenau.de (smail.rz.tu-ilmenau.de [141.24.186.67]) by mails.dpdk.org (Postfix) with ESMTP id 15773400EF for ; Fri, 24 Jun 2022 17:41:45 +0200 (CEST) Received: from [192.168.0.10] (unknown [80.88.29.210]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smail.rz.tu-ilmenau.de (Postfix) with ESMTPSA id B80B3580092; Fri, 24 Jun 2022 17:41:44 +0200 (CEST) Message-ID: Date: Fri, 24 Jun 2022 17:41:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: Large interruptions for EAL thread running on isol core Content-Language: en-US To: Stephen Hemminger Cc: users@dpdk.org References: <9a95a560-c7c6-d4fa-1041-836fa400f497@tu-ilmenau.de> <20220624080124.244a01a9@hermes.local> From: Carsten Andrich In-Reply-To: <20220624080124.244a01a9@hermes.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org I cannot find SCHED_NO_HZ_FULL in v5.18: https://elixir.bootlin.com/linux/latest/A/ident/SCHED_NO_HZ_FULL Could you elaborate? Thanks and best regards, Carsten On 24.06.22 17:01, Stephen Hemminger wrote: > On Thu, 23 Jun 2022 21:03:49 +0200 > Carsten Andrich wrote: > >> 2. Use real-time priority (SCHED_FIFO w/ priority 99) for the DPDK >> threads and >> echo -1 > /proc/sys/kernel/sched_rt_runtime_us >> to disable the runtime limit. With the runtime limit in place, the >> SCHED_FIFO performance will be significantly worse than SCHED_OTHER. > This can cause major issues if application is normal DPDK application (never does system calls). > If an interrupt or other event happens on your isolated CPU, the work that it would > do in soft irq is never performed. FIFO has higher priority than kernel threads. > This can lead to mystery lockups from other applications (reads not completing, network timeouts, etc). > > In any semi-recent kernel using SCHED_NO_HZ_FULL will keep clock ticks from happening > on the isolated cores.