From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <users-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id CF9D545A6C for <public@inbox.dpdk.org>; Mon, 30 Sep 2024 19:27:57 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 992FF4027C; Mon, 30 Sep 2024 19:27:57 +0200 (CEST) Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by mails.dpdk.org (Postfix) with ESMTP id BB1774026C for <users@dpdk.org>; Mon, 30 Sep 2024 19:27:55 +0200 (CEST) Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-20b7a4336easo10376665ad.3 for <users@dpdk.org>; Mon, 30 Sep 2024 10:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1727717275; x=1728322075; 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=obho3Fhfx0iXO/dv3Z2cVDzWNn1BJfAHJg0LfOb0NJI=; b=E+/XAh/4v7jRQ3/3ljPZcYxGJEX79XdljednJrV6W5w1iufxHBTrQDq+p7rDJFtc8R wTYRS5F65MgAx2wHSgBHdm8EmorBfCAwfcHgDd3Jb5NCEiUxvU20hnD1kTsBfv848ILH dsNq87t6Ay0o1BbKQW3Q8JpOWDEz9Fn0CZmm1cp2dNLApiatlPsC+sF/gox9TMV4iv4M QesKMoYKkrOcgAECULgLGMcvXPFrKQKyl+xcerMoYK55nLMOTpB/rW00SeIQ2X/5LgTr zg0VHu15zSNMwqTO/Dj0BC3EsM6Lla6VTbuNtcoKWwHxEnbPiiEqc4MwQjnWeHgB2+Y2 1fzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727717275; x=1728322075; 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=obho3Fhfx0iXO/dv3Z2cVDzWNn1BJfAHJg0LfOb0NJI=; b=gnuhdZ1ICAGujNbQ+yRDzoYCG7QlrzItnuwsSDfY0aG6wirtviyAvN0XNR81X79cBE QNeeQ0siy5k/7fYxSS80XEoHHeWO8BrwLFkTj5lkFyvBj21KKby1aBWlM+6tfJo7R1ir jiGxliSUidyW/vf3Gl0464O9ZbGrP0Gn9TS1MXG+n3KG4uNOABYJWnO4StqTth5aqdfJ IYz0l2HpxVGpSf0ieCzBSIibgBhI3WB67ggpNm1GMr5Xbo4tMG2+9q6J/5/mrPXUv7HB 7r/04DKDiFhtazEnMudfglgRCyiEnTCO+x77wRGGAOFHMICa9H8vLFIDPR97dTqG9Cn7 Y84g== X-Gm-Message-State: AOJu0Yw6i+M0ax3nWLol3szGSQojk1I59zK3So+moX8YjzhAUMxVLTTx BXJxKYKJbHhK1gPIrM/EUKWMMe7SZ1zLEbba+zsp8Avcapt+nBAxwzbz18C1qGU= X-Google-Smtp-Source: AGHT+IG54nveL/LKP1MWpv+H4P50T2u9vV+ubEzfuNuASa0CXEX7T2v/MTbWFV4vNSgIphoP6rUZGg== X-Received: by 2002:a17:903:2344:b0:205:68a4:b2d8 with SMTP id d9443c01a7336-20b36be3f0cmr156500245ad.11.1727717274825; Mon, 30 Sep 2024 10:27:54 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-20b37e20dffsm57064935ad.170.2024.09.30.10.27.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Sep 2024 10:27:54 -0700 (PDT) Date: Mon, 30 Sep 2024 10:27:52 -0700 From: Stephen Hemminger <stephen@networkplumber.org> To: amit sehas <cun23@yahoo.com> Cc: "users@dpdk.org" <users@dpdk.org> Subject: Re: core performance Message-ID: <20240930102752.5ccc5c9f@hermes.local> In-Reply-To: <20240930085726.6df70a01@hermes.local> References: <595544330.11681349.1727123476579.ref@mail.yahoo.com> <595544330.11681349.1727123476579@mail.yahoo.com> <20240930085726.6df70a01@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions <users.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/users>, <mailto:users-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/users/> List-Post: <mailto:users@dpdk.org> List-Help: <mailto:users-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/users>, <mailto:users-request@dpdk.org?subject=subscribe> Errors-To: users-bounces@dpdk.org On Mon, 30 Sep 2024 08:57:26 -0700 Stephen Hemminger <stephen@networkplumber.org> wrote: > > After placing counters all over the code, we realize that some threads are uniformly slow, in other words there is no application level issue that is throttling one thread over the other. We come to the conculsion that either the Cores on which they are running are not at the same frequency which seems doubtful or the threads are not getting a chance to execute on the cores uniformly. > > > > It seems that isolcpus has been deprecated in recent versions of linux. > > > > What is the recommended approach to prevent the kernel from utilizing some CPU threads, for anything other than the threads that are launched on them. > > On modern Linux systems, CPU isolation can be achieved with cgroups. Did you checkout the links in the section in the docs on core isolation. https://doc.dpdk.org/guides/linux_gsg/enable_func.html https://www.suse.com/c/cpu-isolation-practical-example-part-5/ https://www.rcannings.com/systemd-core-isolation/ There is also a much more complex and detailed script which is part of the open source project DanOs here: https://github.com/danos/vyatta-cpu-shield/blob/master/usr/bin/cpu_shield If you really want isolated CPU's you have to some more complex stuff to make sure interrupts etc don't run on that CPU. Also never use CPU 0