From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752892AbdDMNsr (ORCPT ); Thu, 13 Apr 2017 09:48:47 -0400 Received: from mail.kernel.org ([198.145.29.136]:34686 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751114AbdDMNsp (ORCPT ); Thu, 13 Apr 2017 09:48:45 -0400 Date: Thu, 13 Apr 2017 09:48:40 -0400 From: Steven Rostedt To: Peter Zijlstra Cc: LKML , Ingo Molnar , Andrew Morton , "Paul E. McKenney" , Thomas Gleixner Subject: Re: [PATCH v2] sched: Have do_idle() call __schedule() without enabling preemption Message-ID: <20170413094840.347b9829@gandalf.local.home> In-Reply-To: <20170413084453.ad4falb7kc53viri@hirez.programming.kicks-ass.net> References: <20170412142744.6ff07236@gandalf.local.home> <20170413084453.ad4falb7kc53viri@hirez.programming.kicks-ass.net> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 13 Apr 2017 10:44:53 +0200 Peter Zijlstra wrote: > On Wed, Apr 12, 2017 at 02:27:44PM -0400, Steven Rostedt wrote: > > + * schedule_idle() is similar to schedule_preempt_disable() except > > + * that it never enables preemption. > > That's not right. The primary distinction is that it doesn't call > sched_submit_work(). That has nothing to do with fixing synchronize_rcu_tasks(), which is the entire point of my patch, thus it is *not* the primary distinction. Keeping schedule from enabling preemption and calling functions is the bug fix. Not calling sched_submit_work() is just an added optimization benefit. The point of the patch is to stop idle from enabling preemption, because it doesn't need to, as sched_submit_work() is a nop for it. I'll update my change log to mention that. > > And because that function is a no-op for the idle thread, the idle > thread can do without calling that and therefore avoid the preemption > window. > > You also need a few words about fake idle threads, search play_idle() > callers. Thanks, this is the first I heard of these. I'll go look at them. > > You could also make schedule_idle() more robust by adding a WARN for the > blk_schedule_flush_plug() condition. Why? The call to schedule_preempt_disabled() never got that far when coming from do_idle(). static inline void sched_submit_work(struct task_struct *tsk) { if (!tsk->state || tsk_is_pi_blocked(tsk)) return; /* * If we are going to sleep and we have plugged IO queued, * make sure to submit it to avoid deadlocks. */ if (blk_needs_flush_plug(tsk)) blk_schedule_flush_plug(tsk); } Isn't tsk->state always zero for the idle task? A better case would be WARN_ON(tsk->state) > > > You Changelog is still entirely long and rambling but fails to mention > the fundamental important stuff :-( Remember, this patch is to fix a bug and not to optimize idle, although that is an added benefit. The bug I am fixing, which is in linux-next now, is that the idle thread breaks synchronize_rcu_tasks() when calling schedule() with preemption enabled. That's what my ramblings in the change log are talking about. -- Steve