[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1461229794-3654-1-git-send-email-caoj.fnst@cn.fujitsu.com>
Date: Thu, 21 Apr 2016 17:09:54 +0800
From: Cao jin <caoj.fnst@...fujitsu.com>
To: <tglx@...utronix.de>
CC: <corbet@....net>, <linux-kernel@...r.kernel.org>,
<linux-doc@...r.kernel.org>
Subject: [PATCH] hrtimers: doc cleanup
It has:
a tense correction(led->leads);
a typo(unevitably->inevitably);
a logic error correction(unacceptable->acceptable)
Signed-off-by: Cao jin <caoj.fnst@...fujitsu.com>
---
Documentation/timers/hrtimers.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/timers/hrtimers.txt b/Documentation/timers/hrtimers.txt
index ce31f65..347ad82 100644
--- a/Documentation/timers/hrtimers.txt
+++ b/Documentation/timers/hrtimers.txt
@@ -28,10 +28,10 @@ several reasons why such integration is hard/impossible:
- the unpredictable [O(N)] overhead of cascading leads to delays which
necessitate a more complex handling of high resolution timers, which
- in turn decreases robustness. Such a design still led to rather large
+ in turn decreases robustness. Such a design still leads to rather large
timing inaccuracies. Cascading is a fundamental property of the timer
- wheel concept, it cannot be 'designed out' without unevitably
- degrading other portions of the timers.c code in an unacceptable way.
+ wheel concept, it cannot be 'designed out' without inevitably
+ degrading other portions of the timers.c code in an acceptable way.
- the implementation of the current posix-timer subsystem on top of
the timer wheel has already introduced a quite complex handling of
--
2.1.0
Powered by blists - more mailing lists