Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932360AbcLMD5I (ORCPT ); Mon, 12 Dec 2016 22:57:08 -0500 Received: from www.osadl.org ([62.245.132.105]:45362 "EHLO www.osadl.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752175AbcLMD5G (ORCPT ); Mon, 12 Dec 2016 22:57:06 -0500 From: Nicholas Mc Guire To: Thomas Gleixner Cc: Jonathan Corbet , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Nicholas Mc Guire Subject: [PATCH] doc: add note on usleep_range range Date: Tue, 13 Dec 2016 04:58:43 +0100 Message-Id: <1481601523-14004-1-git-send-email-hofrat@osadl.org> X-Mailer: git-send-email 2.1.4 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1525 Lines: 40 useleep_range() with a delta of 0 makes no sense and only prevents the timer subsystem from optimizing interrupts. As any user of usleep_range() is in non-atomic context the timer jitter is in the range of 10s of microseconds anyway. This adds a note making it clear that a range of 0 is a bad idea. Signed-off-by: Nicholas Mc Guire --- as of 4.9.0 there are about 20 cases of usleep_ranges() that have min==max and none of them really look like they are necessary, so it does seem like a relatively common misunderstanding worth noting in the documentation. Patch is against 4.9.0 (localversion-next is 20161212) Documentation/timers/timers-howto.txt | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/Documentation/timers/timers-howto.txt b/Documentation/timers/timers-howto.txt index 038f8c7..b5cdf82 100644 --- a/Documentation/timers/timers-howto.txt +++ b/Documentation/timers/timers-howto.txt @@ -93,6 +93,13 @@ NON-ATOMIC CONTEXT: tolerances here are very situation specific, thus it is left to the caller to determine a reasonable range. + A range of 0, that is usleep_range(100,100) or the + like, do not make sense as this code is in a + non-atomic section and a system can not be expected + to have jitter 0. For any non-RT code any delta + less than 50 microseconds probably is only preventing + timer subsystem optimization but providing no benefit. + SLEEPING FOR LARGER MSECS ( 10ms+ ) * Use msleep or possibly msleep_interruptible -- 2.1.4