linux-kernel - Re: [RFC][PATCH 0/8] sched,idle: need resched polling rework

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] [day] [month] [year] [list]

Message-ID: <CALCETrWO-H2Xh0E42THgL71FkBfGr5L1yykcoVznJdbU+qgEqw@mail.gmail.com>
Date:	Tue, 3 Jun 2014 13:07:27 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>, nicolas.pitre@...aro.org,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Mike Galbraith <umgwanakikbuti@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH 0/8] sched,idle: need resched polling rework

On Tue, Jun 3, 2014 at 11:44 AM, Andy Lutomirski <luto@...capital.net> wrote:
> On Tue, Jun 3, 2014 at 11:28 AM, Peter Zijlstra <peterz@...radead.org> wrote:
>> On Tue, Jun 03, 2014 at 07:00:18PM +0200, Peter Zijlstra wrote:
>>> On Tue, Jun 03, 2014 at 09:52:22AM -0700, Andy Lutomirski wrote:
>>> > > So you could cheat and set it in pick_next_task_idle() and clear in
>>> > > put_prev_task_idle(), that way the entire idle loop, when running has it
>>> > > set.
>>> > >
>>> >
>>> > Isn't that a little late for sched_ttwu_pending?  I guess it could be
>>> > okay, but I'm hesitant to muck around with the scheduler innards that
>>> > much.  I don't see anything that'll break, though.
>>>
>>> Yeah, only later did I see you clear much earlier, which makes sense.
>>
>> Could we clear it from set_nr_and_not_polling()/set_nr_if_polling()?
>> That's the only two functions that'll kick a cpu out of its polling
>> loop, and we're already writing to the word anyhow.
>
> I'd be nervous about this.  I think it could break if
> cpuidle_idle_call decides not to idle for any reason, and there is
> plenty of complicated code in there.
>
> I'm currently working on some patches that might make this clearer.
> Give me a bit.

The code's here:

https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=sched_ipi

In summary, here's what it does:

 - Fix poll_idle to set polling.

 - Add a new tracepoint for polling wakeups -- this makes it much
easier to verify that the code is doing something.

 - Make it so that polling is only set when the idle task is actually
paying attention.

 - Clean up wake_up_idle_cpu

 - More or less your earlier, more aggressive patch, with the
CONFIG_SMP thing fixed and waking rq->idle instead of the task to be
woken in ttwu.

This has survived my trading software for about twenty minutes, and
latency monitoring doesn't show any signs of missed wakeups.  If it
survives awhile longer and the kbuild robot doesn't complain, I'll
send out patches.

--Andy
--
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/