From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 03:01:15 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DA7816A41F for ; Sat, 18 Jun 2005 03:01:15 +0000 (GMT) (envelope-from ups@tree.com) Received: from smtp.speedfactory.net (talon.speedfactory.net [66.23.216.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id E094D43D55 for ; Sat, 18 Jun 2005 03:01:14 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 396 invoked from network); 18 Jun 2005 03:01:16 +0000 Received: from 66-23-216-49.clients.speedfactory.net (HELO palm.tree.com) (66.23.216.49) by smtp.speedfactory.net with AES256-SHA encrypted SMTP; 18 Jun 2005 03:01:16 +0000 Received: from [127.0.0.1] (ups@localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id j5I31CpP044610; Fri, 17 Jun 2005 23:01:13 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: Daniel Eriksson In-Reply-To: <4F9C9299A10AE74E89EA580D14AA10A6028579@royal64.emp.zapto.org> References: <4F9C9299A10AE74E89EA580D14AA10A6028579@royal64.emp.zapto.org> Content-Type: text/plain Message-Id: <1119063671.27369.134679.camel@palm> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 17 Jun 2005 23:01:11 -0400 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: IPI_PREEMPTION, something to test for normal users? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2005 03:01:15 -0000 On Thu, 2005-06-16 at 04:01, Daniel Eriksson wrote: > On a regular SMP server running 6-CURRENT, is IPI_PREEMPTION something > to try? > I've looked around for an explanation of what it does and what possible > pitfalls there are, but I haven't really found anything. It's only in > NOTES at the moment, indicating that it isn't for general consumption > yet(?). IPI_PREEMPTION allows the scheduler running on CPU A to preempt a thread on CPU B. This should reduce latency in some circumstances. More benchmarks are needed to find out if this actually helps or if additional context switch overhead slows down typical workloads. The preemption IPI could also be (ab)used later to add security fixes for hyperthreading as proposed by Colin Percival. Stephan