diff for duplicates of <20161002055951.GU14933@linux.vnet.ibm.com> diff --git a/a/1.txt b/N1/1.txt index 9e0658a..d13d52b 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -21,9 +21,9 @@ On Sat, Oct 01, 2016 at 11:59:25PM -0400, Rich Felker wrote: > > > > > > obviously either getting out of idle and then moves the tick ahead for some > > > > > > unknown reason. > > > > > -> > > > > And a one-jiffy timeout is in fact expected behavior when HZ\x100. -> > > > > You have to be running HZ%0 or better to have two-jiffy timeouts, -> > > > > and HZP0 or better for three-jiffy timeouts. +> > > > > And a one-jiffy timeout is in fact expected behavior when HZ=100. +> > > > > You have to be running HZ=250 or better to have two-jiffy timeouts, +> > > > > and HZ=500 or better for three-jiffy timeouts. > > > > > > > > One possible theory I'm looking at is that the two cpus are both > > > > waking up (leaving cpu_idle_poll or cpuidle_idle_call) every jiffy @@ -77,7 +77,7 @@ This is the RCU logic you are missing within the RCU grace-period kthread: ret = swait_event_interruptible_timeout(rsp->gp_wq, rcu_gp_fqs_check_wake(rsp, &gf), j); -On your system, j=1, which means that when the RCU grace-period kthread +On your system, j==1, which means that when the RCU grace-period kthread sleeps during a grace period, it is supposed to be awakened after one jiffy regardless of anything else. On your system (and apparently -only- your system), this wakeup is not happening. diff --git a/a/content_digest b/N1/content_digest index 6f851ad..e3f3441 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -10,7 +10,7 @@ "ref\020161002035925.GQ19318@brightrain.aerifal.cx\0" "From\0Paul E. McKenney <paulmck@linux.vnet.ibm.com>\0" "Subject\0Re: [PATCH v7 2/2] clocksource: add J-Core timer/clocksource driver\0" - "Date\0Sun, 02 Oct 2016 05:59:51 +0000\0" + "Date\0Sat, 1 Oct 2016 22:59:51 -0700\0" "To\0Rich Felker <dalias@libc.org>\0" "Cc\0Thomas Gleixner <tglx@linutronix.de>" Daniel Lezcano <daniel.lezcano@linaro.org> @@ -44,9 +44,9 @@ "> > > > > > obviously either getting out of idle and then moves the tick ahead for some\n" "> > > > > > unknown reason.\n" "> > > > > \n" - "> > > > > And a one-jiffy timeout is in fact expected behavior when HZ\0200.\n" - "> > > > > You have to be running HZ%0 or better to have two-jiffy timeouts,\n" - "> > > > > and HZP0 or better for three-jiffy timeouts.\n" + "> > > > > And a one-jiffy timeout is in fact expected behavior when HZ=100.\n" + "> > > > > You have to be running HZ=250 or better to have two-jiffy timeouts,\n" + "> > > > > and HZ=500 or better for three-jiffy timeouts.\n" "> > > > \n" "> > > > One possible theory I'm looking at is that the two cpus are both\n" "> > > > waking up (leaving cpu_idle_poll or cpuidle_idle_call) every jiffy\n" @@ -100,7 +100,7 @@ "\t\t\tret = swait_event_interruptible_timeout(rsp->gp_wq,\n" "\t\t\t\t\trcu_gp_fqs_check_wake(rsp, &gf), j);\n" "\n" - "On your system, j=1, which means that when the RCU grace-period kthread\n" + "On your system, j==1, which means that when the RCU grace-period kthread\n" "sleeps during a grace period, it is supposed to be awakened after one\n" "jiffy regardless of anything else. On your system (and apparently -only-\n" "your system), this wakeup is not happening.\n" @@ -146,4 +146,4 @@ "\n" "\t\t\t\t\t\t\tThanx, Paul" -912fa38dd4569e03766880666f2314688f2ce059e6368ecc2893bf080887ddc7 +1ac9460823143568c12b097ad213e71df5981bb60b694cbf3eb6bd33ca0200d9
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.