Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753302AbbBSRI2 (ORCPT ); Thu, 19 Feb 2015 12:08:28 -0500 Received: from cantor2.suse.de ([195.135.220.15]:35719 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752654AbbBSRI0 (ORCPT ); Thu, 19 Feb 2015 12:08:26 -0500 Date: Thu, 19 Feb 2015 18:08:24 +0100 (CET) From: Jiri Kosina To: Josh Poimboeuf cc: Vojtech Pavlik , Peter Zijlstra , Andrew Morton , Ingo Molnar , Seth Jennings , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] sched: add sched_task_call() In-Reply-To: <20150219170353.GB15980@treble.redhat.com> Message-ID: References: <20150217141211.GC11861@treble.redhat.com> <20150217181541.GP5029@twins.programming.kicks-ass.net> <20150217212532.GJ11861@treble.redhat.com> <20150218152100.GZ5029@twins.programming.kicks-ass.net> <20150218171256.GA28553@treble.hsd1.ky.comcast.net> <20150219002058.GD5029@twins.programming.kicks-ass.net> <20150219041753.GA13423@treble.redhat.com> <20150219101607.GG5029@twins.programming.kicks-ass.net> <20150219162429.GA15980@treble.redhat.com> <20150219163359.GA25438@suse.cz> <20150219170353.GB15980@treble.redhat.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1401 Lines: 36 On Thu, 19 Feb 2015, Josh Poimboeuf wrote: > > > > No, these tasks will _never_ make syscalls. So you need to guarantee > > > > they don't accidentally enter the kernel while you flip them. Something > > > > like so should do. > > > > > > > > You set TIF_ENTER_WAIT on them, check they're still in userspace, flip > > > > them then clear TIF_ENTER_WAIT. > > > > > > Ah, that's a good idea. But how do we check if they're in user space? > > > > I don't see the benefit in holding them in a loop - you can just as well > > flip them from the syscall code as kGraft does. > > But we were talking specifically about HPC tasks which never make > syscalls. Yeah. And getting answer to "is this task_struct currently running in userspace?" is not easy in a non-disruptive way. Piggy-backing on CONFIG_CONTEXT_TRACKING is one option, but I guess the number of systems that have this option turned on will be rather limited (especially in HPC space). Sending IPIs around to check whether the task is running in user-space or kernel-space would work, but it's disruptive to the running task, which might be unwanted as well. -- Jiri Kosina SUSE Labs -- 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/