From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sven-Thorsten Dietrich Subject: [PATCH] cleanup sched_yield (sys)call nesting. Date: Wed, 18 Nov 2009 12:46:34 -0800 Message-ID: <1258577194.12429.86.camel@sven.thebigcorporation.com> References: <20091107210147.3e754278@hyperion.delvare> <4AF7148C.9090706@thebigcorporation.com> <20091112211255.09cd884a@hyperion.delvare> <20091116155606.GC29479@sirena.org.uk> <20091118010520.4cd397d4@lxorguk.ukuu.org.uk> <20091118175202.490989d8@hyperion.delvare> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Leon Woestenberg , Alan Cox , Mark Brown , Thomas Gleixner , linux-i2c@vger.kernel.org, rt-users , "Ben Dooks (embedded platforms)" , Peter Zijlstra , LKML To: Jean Delvare Return-path: Received: from mail-bw0-f227.google.com ([209.85.218.227]:61365 "EHLO mail-bw0-f227.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752130AbZKRUqi (ORCPT ); Wed, 18 Nov 2009 15:46:38 -0500 In-Reply-To: <20091118175202.490989d8@hyperion.delvare> Sender: linux-rt-users-owner@vger.kernel.org List-ID: On Wed, 2009-11-18 at 17:52 +0100, Jean Delvare wrote: > On Wed, 18 Nov 2009 17:28:53 +0100, Leon Woestenberg wrote: > > On Wed, Nov 18, 2009 at 2:05 AM, Alan Cox wrote: > > > Our timers are very efficient and some day we will need to make jiffies a > > > function and stop the timer ticking for best performance. At that point > > > timers are probably the most efficient way to do much of this. > > > > The problem with I2C bitbanged is the stringent timing, we need a way > > to have fine-grained sleeping > > mixed with real-time tasks in order to make this work. > > FWIW, the problem that was initially reported has nothing to do with > this. i2c-algo-bit used mdelay() during transactions, not yield(). > yield() is used only in once place, _between_ transactions attempts. > There are no strict timing constraints there. > I agree that dropping out sched_yield entirely should maybe start by deprecating / flagging as a warning in sched_rt.c. This is just a minimal cleanup I stumbled across while looking at it - to get away from the uglyness of calling into the syscall interface from inside the Kernel. I'll generate something more substantial for discussion later. Subject: clean up chaining in sched_yield() From: Sven-Thorsten Dietrich The call to sys_sched_yield for in-Kernel is messy. and the return code from sys_sched_yield is ignored when called from in-kernel. Signed-off-by: Sven-Thorsten Dietrich diff --git a/kernel/sched.c b/kernel/sched.c index 3c11ae0..db2c0f9 100644 --- a/kernel/sched.c +++ b/kernel/sched.c @@ -6647,12 +6647,12 @@ SYSCALL_DEFINE3(sched_getaffinity, pid_t, pid, unsigned int, len, } /** - * sys_sched_yield - yield the current processor to other threads. + * do_sched_yield - yield the current processor to other threads. * * This function yields the current CPU to other tasks. If there are no * other threads running on this CPU then this function will return. */ -SYSCALL_DEFINE0(sched_yield) +static inline void do_sched_yield(void) { struct rq *rq = this_rq_lock(); @@ -6669,6 +6669,11 @@ SYSCALL_DEFINE0(sched_yield) preempt_enable_no_resched(); schedule(); +} + +SYSCALL_DEFINE0(sched_yield) +{ + do_sched_yield(); return 0; } @@ -6746,7 +6751,7 @@ EXPORT_SYMBOL(__cond_resched_softirq); void __sched yield(void) { set_current_state(TASK_RUNNING); - sys_sched_yield(); + do_sched_yield(); } EXPORT_SYMBOL(yield);