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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAFTL4hywucK7_d2V-wYkhagu0+izYz_MTFNJEHEsaTvoZBXwMg@mail.gmail.com>
Date:	Thu, 21 Mar 2013 21:42:00 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Christoph Lameter <cl@...ux.com>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	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

2013/3/21 Christoph Lameter <cl@...ux.com>:
> On Thu, 21 Mar 2013, Paul E. McKenney wrote:
>> 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.

It sounds that simple but it's more complicated. It requires some more
hooks on the scheduler, namely in the sched_switch/dequeue path so
that when the last task of a class goes to sleep, we check what else
is running and whether we need to restart the tick or not depending on
the class of the next task and how many tasks are there.

This will probably need to go in sched_class::dequeue_task(). There is
some careful and subtle attention to put on that.

Of course we want to improve that in the long run. But for now we have
a KISS solution that works. And like Steve said, the patchset is
complicated enough. Move baby steps forward to ease the upstream
integration.

> 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?

Sure, for now just don't use SCHED_FIFO and you will have a much more
extended dynticks coverage.
--
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/