From owner-freebsd-smp Mon Sep 20 18:44:32 1999 Delivered-To: freebsd-smp@freebsd.org Received: from mail.rdc1.sfba.home.com (ha1.rdc1.sfba.home.com [24.0.0.66]) by hub.freebsd.org (Postfix) with ESMTP id 30BDA14C89 for ; Mon, 20 Sep 1999 18:44:31 -0700 (PDT) (envelope-from adsharma@c62443-a.frmt1.sfba.home.com) Received: from c62443-a.frmt1.sfba.home.com ([24.0.69.165]) by mail.rdc1.sfba.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990921014430.GLFH29487.mail.rdc1.sfba.home.com@c62443-a.frmt1.sfba.home.com> for ; Mon, 20 Sep 1999 18:44:30 -0700 Received: (from adsharma@localhost) by c62443-a.frmt1.sfba.home.com (8.9.3/8.9.3) id SAA16575 for freebsd-smp@freebsd.org; Mon, 20 Sep 1999 18:44:30 -0700 Date: Mon, 20 Sep 1999 18:44:30 -0700 From: Arun Sharma To: freebsd-smp@freebsd.org Subject: Context switch code structure Message-ID: <19990920184430.A16551@home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org After the recent change to move the "chooseproc" logic from assembly to C, I wondered if the code should be restructured in a different way. Right now, it approximately looks like: proc = chooseproc Now, if one day FreeBSD achieves fine grained locking and there are multiple CPUs in the kernel mode, which means certain conditions can change over time, underneath the current process. Specifically, if the current process is the most eligible process after context switching out, then we switch to the same process wasting a bunch of CPU cycles. Are there any guarantees that this can't happen ? If not, would it make sense to restructure the algorithm to do: proc = chooseproc switch(current, proc) -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message