linux-kernel - Re: [PATCH] nohz1: Documentation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0000013d8e8d24fd-d2931c45-2722-46d1-8b47-2ef11e21096d-000000@email.amazonses.com>
Date:	Thu, 21 Mar 2013 20:04:08 +0000
From:	Christoph Lameter <cl@...ux.com>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
cc:	Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Rob Landley <rob@...dley.net>, linux-kernel@...r.kernel.org,
	josh@...htriplett.org, zhong@...ux.vnet.ibm.com,
	khilman@...aro.org, geoff@...radead.org, tglx@...utronix.de
Subject: Re: [PATCH] nohz1: Documentation

On Thu, 21 Mar 2013, Paul E. McKenney wrote:

> > Yeah doing that right now but I'd like to see it handled without manual
> > intervention.
>
> Given that RCU has no idea where you want them to run, some manual
> intervention would most likely be required even if RCU spawned them
> dynamically, right?

If rcuoXX is a SCHED_OTHER process/thread then the kernel will move it to
another processor from the one running the SCHED_FIFO task. There would be
no manual intervention required.

> So, again, removing scheduling-clock interrupts in more situations is
> a good future enhancement.

The point here is that the check for a single runnable process is wrong
because it accounts for tasks in all scheduling classes.

It would be better to check if there is only one runnable task in the
highest scheduling class. That would work and defer the SCHED_OTHER kernel
threads for the SCHED_FIFO thread.

I am wondering how you actually can get NOHZ to work right? There is
always a kernel thread that is scheduled in a couple of ticks.

I guess what will happens with this patchset is:

1. SCHED_FIFO thread begins to run. There is only a single runnable task
so adaptive tick mode is enabled.

2. After 2 seconds or so some or other thing needs to run (keventd thread
needs to run vm statistics f.e.). It becomes runnable. nr_running > 1.
Adaptive tick mode is disabled? Occurs on my system. Or is there some
other trick to avoid kernel threads becoming runnable?

3. Now there are 2 runnable processes. The SCHED_FIFO thread continues to
run with the tick. The kernel thread is also runnable but will not be
given cpu time since the SCHED_FIFO thread has priority?

So the SCHED_FIFO thread enjoys 2 seconds of no tick time and then ticks
occur uselessly from there on?

I have not been able to consistently get the tick switched off with
the nohz patchset. How do others use nohz? Is it only usable for short
periods of less than 2 seconds?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/