From owner-freebsd-arch@FreeBSD.ORG Sun May 22 00:34:37 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71EDE16A41C; Sun, 22 May 2005 00:34:37 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 297C843D1F; Sun, 22 May 2005 00:34:37 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j4M0YalD022912; Sat, 21 May 2005 17:34:37 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <428FC00B.3080909@freebsd.org> References: <428FC00B.3080909@freebsd.org> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sat, 21 May 2005 17:34:37 -0700 To: Colin Percival X-Mailer: Apple Mail (2.622) cc: freebsd-arch@freebsd.org Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 00:34:37 -0000 On May 21, 2005, at 4:11 PM, Colin Percival wrote: *snip* > The following must be done before hyperthreading is re-enabled: > > 1. The scheduler must be taught to not run threads on the same > processor core unless they p_candebug() each other. For reasons > of performance and locking, this is probably best accomplished by > only allowing threads to share a processor core if they belong > to the same process. > 2. When a thread is in the kernel, there must be a mechanism for > it to IPI its siblings and put them to sleep, and then wake them > up later. This would be used any time when a thread in the kernel > is about to handle sensitive data in a non-oblivious manner; IPsec > is a good example of where this would be necessary. > > Does anyone want to step forward to work on this? Maybe it's a better idea to describe the problem in much more detail, rather than dictate what you want someone else to do? A pointer to where the problem is described/discussed would do. Just a thought, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net