From owner-svn-src-stable@FreeBSD.ORG Sun Jan 29 00:32:38 2012 Return-Path: Delivered-To: svn-src-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0439D106566C; Sun, 29 Jan 2012 00:32:38 +0000 (UTC) (envelope-from marius@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c]) by mx1.freebsd.org (Postfix) with ESMTP id D81FD8FC15; Sun, 29 Jan 2012 00:32:37 +0000 (UTC) Received: from svn.freebsd.org (localhost [127.0.0.1]) by svn.freebsd.org (8.14.4/8.14.4) with ESMTP id q0T0Wb0t006922; Sun, 29 Jan 2012 00:32:37 GMT (envelope-from marius@svn.freebsd.org) Received: (from marius@localhost) by svn.freebsd.org (8.14.4/8.14.4/Submit) id q0T0WbJB006920; Sun, 29 Jan 2012 00:32:37 GMT (envelope-from marius@svn.freebsd.org) Message-Id: <201201290032.q0T0WbJB006920@svn.freebsd.org> From: Marius Strobl Date: Sun, 29 Jan 2012 00:32:37 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-9@freebsd.org X-SVN-Group: stable-9 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: svn commit: r230691 - stable/9/sys/kern X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 00:32:38 -0000 Author: marius Date: Sun Jan 29 00:32:37 2012 New Revision: 230691 URL: http://svn.freebsd.org/changeset/base/230691 Log: MFC: r226057 - Currently, sched_balance_pair() may cause a CPU to send an IPI_PREEMPT to itself, which sparc64 hardware doesn't support. One way to solve this would be to directly call sched_preempt() instead of issuing a self-IPI. However, quoting jhb@: "On the other hand, you can probably just skip the IPI entirely if we are going to send it to the current CPU. Presumably, once this routine finishes, the current CPU will exit softlock (or will do so "soon") and will then pick the next thread to run based on the adjustments made in this routine, so there's no need to IPI the CPU running this routine anyway. I think this is the better solution. Right now what is probably happening on other platforms is as soon as this routine finishes the CPU processes its self-IPI and causes mi_switch() which will just switch back to the softclock thread it is already running." - With r226054 (MFC'ed to stable/9 in r230690) and the the above change in place, sparc64 now no longer is incompatible with ULE and vice versa. However, powerpc/E500 still is. Submitted by: jhb Reviewed by: jeff Modified: stable/9/sys/kern/sched_ule.c Directory Properties: stable/9/sys/ (props changed) stable/9/sys/amd64/include/xen/ (props changed) stable/9/sys/boot/ (props changed) stable/9/sys/boot/i386/efi/ (props changed) stable/9/sys/boot/ia64/efi/ (props changed) stable/9/sys/boot/ia64/ski/ (props changed) stable/9/sys/boot/powerpc/boot1.chrp/ (props changed) stable/9/sys/boot/powerpc/ofw/ (props changed) stable/9/sys/cddl/contrib/opensolaris/ (props changed) stable/9/sys/conf/ (props changed) stable/9/sys/contrib/dev/acpica/ (props changed) stable/9/sys/contrib/octeon-sdk/ (props changed) stable/9/sys/contrib/pf/ (props changed) stable/9/sys/contrib/x86emu/ (props changed) Modified: stable/9/sys/kern/sched_ule.c ============================================================================== --- stable/9/sys/kern/sched_ule.c Sun Jan 29 00:24:46 2012 (r230690) +++ stable/9/sys/kern/sched_ule.c Sun Jan 29 00:32:37 2012 (r230691) @@ -76,7 +76,7 @@ dtrace_vtime_switch_func_t dtrace_vtime_ #include #include -#if defined(__sparc64__) +#if defined(__powerpc__) && defined(E500) #error "This architecture is not currently compatible with ULE" #endif @@ -839,6 +839,7 @@ sched_balance_pair(struct tdq *high, str int low_load; int moved; int move; + int cpu; int diff; int i; @@ -860,10 +861,14 @@ sched_balance_pair(struct tdq *high, str for (i = 0; i < move; i++) moved += tdq_move(high, low); /* - * IPI the target cpu to force it to reschedule with the new - * workload. + * In case the target isn't the current cpu IPI it to force a + * reschedule with the new workload. */ - ipi_cpu(TDQ_ID(low), IPI_PREEMPT); + cpu = TDQ_ID(low); + sched_pin(); + if (cpu != PCPU_GET(cpuid)) + ipi_cpu(cpu, IPI_PREEMPT); + sched_unpin(); } tdq_unlock_pair(high, low); return (moved);