Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933152AbbHZP06 (ORCPT ); Wed, 26 Aug 2015 11:26:58 -0400 Received: from mail-wi0-f177.google.com ([209.85.212.177]:32853 "EHLO mail-wi0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755610AbbHZP0z (ORCPT ); Wed, 26 Aug 2015 11:26:55 -0400 Date: Wed, 26 Aug 2015 17:26:52 +0200 From: Frederic Weisbecker To: Chris Metcalf Cc: Gilad Ben Yossef , Steven Rostedt , Ingo Molnar , Peter Zijlstra , Andrew Morton , Rik van Riel , Tejun Heo , Thomas Gleixner , "Paul E. McKenney" , Christoph Lameter , Viresh Kumar , Catalin Marinas , Will Deacon , linux-doc@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 2/6] cpu_isolated: add initial support Message-ID: <20150826152651.GA11992@lerouge> References: <1438112980-9981-1-git-send-email-cmetcalf@ezchip.com> <1438112980-9981-3-git-send-email-cmetcalf@ezchip.com> <20150812160020.GG21542@lerouge> <55CB8ED1.6030806@ezchip.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55CB8ED1.6030806@ezchip.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2658 Lines: 69 On Wed, Aug 12, 2015 at 02:22:09PM -0400, Chris Metcalf wrote: > On 08/12/2015 12:00 PM, Frederic Weisbecker wrote: > >>+#ifdef CONFIG_CPU_ISOLATED > >>+void cpu_isolated_wait(void) > >>+{ > >>+ set_current_state(TASK_INTERRUPTIBLE); > >>+ _cpu_idle(); > >>+ set_current_state(TASK_RUNNING); > >>+} > >I'm still uncomfortable with that. A wake up model could work? > > I don't know exactly what you have in mind. The theory is that > at this point we're ready to return to user space and we're just > waiting for a timer tick that is guaranteed to arrive, since there > is something pending for the timer. Hmm, ok I'm going to discuss that in the new version. One worry is that it gets racy and we sleep there for ever. > > And, this is an arch-specific method anyway; the generic method > is actually checking to see if a signal has been delivered, > scheduling is needed, etc., each time around the loop, so if > you're not sure your architecture will do the right thing, just > don't provide a method that idles while waiting. For tilegx I'm > sure it works correctly, so I'm OK providing that method. Yes but we do busy waiting on all other archs then. And since we can wait for a while there, it doesn't look sane. > >>diff --git a/include/linux/sched.h b/include/linux/sched.h > >>index 04b5ada460b4..0bb248385d88 100644 > >>--- a/include/linux/sched.h > >>+++ b/include/linux/sched.h > >>@@ -1776,6 +1776,9 @@ struct task_struct { > >> unsigned long task_state_change; > >> #endif > >> int pagefault_disabled; > >>+#ifdef CONFIG_CPU_ISOLATED > >>+ unsigned int cpu_isolated_flags; > >>+#endif > >Can't we add a new flag to tsk->flags? There seem to be some values remaining. > > Yeah, I thought of that, but it seems like a pretty scarce resource, > and I wasn't sure it was the right thing to do. Also, I'm not actually > sure why the lowest two bits aren't apparently being used Probably they were used but got removed. > looks > like PF_EXITING (0x4) is the first bit used. And there are only three > more bits higher up in the word that are not assigned. Which makes room for 5 :) > > Also, right now we are allowing users to customize the signal delivered > for STRICT violation, and that signal value is stored in the > cpu_isolated_flags word as well, so we really don't have room in > tsk->flags for all of that anyway. Yeah indeed, ok lets keep it that way for now. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/