From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 368E53FE37C for ; Wed, 3 Jun 2026 09:59:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780480774; cv=none; b=BzNP5LTlogui/s9XXdaV/TuJyk5cflAmjFRBW3uH8TGkhZvXKHhma+hgVn6Ps5mwKLXYBAhbqgia0cNYpVCJTVJvUDnXOXH53GP1c3AIrCxOHJlhr7K+BTnLGRRey5GD7ZtfOGIyAk+OdzmOy0VrV9Cr3wKbb9D6cltwUIo5Fx8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780480774; c=relaxed/simple; bh=WWE66kO5ap0KRWA3dusn2GSl1woyLWp9FPX8roDin/E=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=bzsQj0hxRcNvWypHNTkN2iLKoY/mEP/BMI6YGes8vKeE1inOzF3/EUX8yLPLs7TXAYmpL6f02tW5EfbosBxOXgvgL05Op0XhCYRE3XOLDMeOJ9UPXllfavAItS/Rz5WAYZPH6rDL/WfAlGOU7ysBQkchoIlfXJmK0gfDhe8hpGo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=d9J2qvtD; arc=none smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="d9J2qvtD" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4903d730b1fso113224885e9.2 for ; Wed, 03 Jun 2026 02:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780480772; x=1781085572; darn=vger.kernel.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=hqrPyJYUf1uiAVLQGGWXV0g7+QvPUPnWlHlluxYaVzA=; b=d9J2qvtDEBPKhJ+nDTCWy8M6zPrMJqJq2Mn8uOcIz+neK9iUtP1941ERXVSEqZoQsM mLImxgbPIhGsaXlpN/pSgVNvIkpdZQ4gLgTmHxYLWB1p+D9IZZh6N8eLQvORyk2rNDXw CfOUjfVZktNXO7p1vWqUwaOjiNna2973inY7NHvbSRvh29Po/sMXbV67S0zPKbSQ2qmt Q3YNbPPhwyPTcpgj2qld74OFAt73q2SKbQQq3tk6kPjiwnHh2YSyBujHfL9bC8OrLvoo 88mB0eU9L5iNEKgVtGz7mOKN5hJ8M9BqeURKSSy5AUXQi+vDz2C4zO3ncEb3UqZrV6+e plow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780480772; x=1781085572; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=hqrPyJYUf1uiAVLQGGWXV0g7+QvPUPnWlHlluxYaVzA=; b=IyRkEWiFblQDOZ7mvNr9hNYyu0NWslDuJ7H98ZkXc7KRZrp+BxfBlTLnqvFvj4kvyG rXuEPsK2qdhcUxjF09fkKZATPru3gYiWsroawdYNWK6tOko3kDnJacDFqTTua9EHlDhw gQdIr2k96VunmCK/kbx+S5CB0SDxcj07jutMrgj7EQXPNdktlNWyOTRJULRzGvtk/bEb hAx45944tvwmnOXVJmXvd4lzBy3z22iMSTOlt3+RYq1mLh21XrtcQi6XtZct3zX9psZE 77w++uNWsfeBXvSC5KiDxBeiZ9NsNO35lzy1Y/G7+TcVEMfB1AOnR7HaYKCbEIvUFGmV RxcQ== X-Forwarded-Encrypted: i=1; AFNElJ+QYB626HTwu+ZzJUwx+/2+G1HhyH2dyhF3Bk8YgIoZnuX0hp6IoMXmBpjNGYI+hxmoFuxda4I5qoldbOY=@vger.kernel.org X-Gm-Message-State: AOJu0Yz6b7jdXQ2zUgbP88ofiNH3VZJiqQam1H2Zx5ht5vUqv+GCsCxO bDp1fl8LATeBhfC3A/+h7U79BMsFzw2S2Y3o8JIR3eyWloMlVF27Y0MW X-Gm-Gg: Acq92OE8P8V5xeNHSSZnbL0aVQ0ZCOm7cUAYIDeRUy5BxXVideHD9KjKeHFLr84VV2j pRw6W4fLa4xNc6GEZkw/BVr79U3uEs60JzuZ3fHWih5/+oIY3f88tv828tDT4W7Nf2mRhwJPWCI 93t4TEidS5Eq5PzyxLrQXX4o8q6dQGiAr7tugxXcqYlzl2089HKYkPKavDb5SPYKnGxnREbpbr1 bAAmV4AixPSKw0EQ1LT72T5eamIb1sCw9FswD8sXJfO12mrU3jaCV+omEh1/EhMvWSBJxUtQP35 VsPWUKm9o0QFW/KArmU/FMigE94MdOC5KAtzyxSWbuAe7FqmJvYhszA70CZeBBeTi7Foy5A8qq/ kT/Qk/3JlqcpdWkEtfqbTrrGbZuPeMyLxE5dQohuIG06ElBgEjw1ORiuzwxUDiIg4v5U/VPLnRz OrR00zp4jZ0jGYBAh2e26NzokslzQylws/Z9UOHJGCHcWKgQdPwoxmOJLYMf4waWOZhkYH1Yg= X-Received: by 2002:a05:600c:46ce:b0:490:b4e5:ce7e with SMTP id 5b1f17b1804b1-490b5edcbe3mr37338725e9.25.1780480771473; Wed, 03 Jun 2026 02:59:31 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490b0e1410esm133565345e9.1.2026.06.03.02.59.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2026 02:59:31 -0700 (PDT) Date: Wed, 3 Jun 2026 10:59:29 +0100 From: David Laight To: Alexander Lobakin Cc: Justin Lai , , , , , , , , , , Subject: Re: [PATCH] rtase: Avoid sleeping in get_stats64() Message-ID: <20260603105929.5f278675@pumpkin> In-Reply-To: References: <20260601062447.64027-1-justinlai0215@realtek.com> <20260601224203.5d282c21@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 2 Jun 2026 15:43:04 +0200 Alexander Lobakin wrote: > From: David Laight > Date: Mon, 1 Jun 2026 22:42:03 +0100 > > > On Mon, 1 Jun 2026 15:14:50 +0200 > > Alexander Lobakin wrote: > > > >> From: Justin Lai > >> Date: Mon, 1 Jun 2026 14:24:47 +0800 > >> > >>> The .ndo_get_stats64 callback must not sleep because it can be > >>> called when reading /proc/net/dev. > >>> > >>> rtase_get_stats64() calls rtase_dump_tally_counter(), which polls > >>> the tally counter dump bit with read_poll_timeout(). This may > >>> sleep while waiting for the hardware counter dump to complete. > >>> > >>> Use read_poll_timeout_atomic() instead to avoid sleeping in the > >>> get_stats64() path. > >>> > >>> Signed-off-by: Justin Lai > >> > >> Looks legit. > >> > >> One question: for how long can this poll for in real life scenarios? Up > >> to ~1 ms is okay-ish for atomic, but if longer, then you'd better to > >> split it into shorter polls and reschedule() time to time. > > > > Anyone trying to get a thread running at an RT priority won't thank you > > for spinning for anywhere near that long. > > When an RT processes becomes runnable the scheduler will preempt a lower > > priority process that is running on the cpu the RT process last ran on. > > The RT process won't run until the preempt actually happens. > > > > 1ms is a very long time. > > That's why I wrote "okay-ish". Ideally atomic polling should not go past > 100 us, I usually used it for no longer than 10-50 us. > > The author says that it usually takes around 25 us which is acceptable > I'd say. Just about :-) Would anyone notice if the read stats code returned slightly old values and did a async request to get the current ones? Probably more work for a back-port though. -- David > > Thanks, > Olek >