From owner-freebsd-current Thu Nov 5 15:15:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA17101 for freebsd-current-outgoing; Thu, 5 Nov 1998 15:15:36 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA17091 for ; Thu, 5 Nov 1998 15:15:34 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40365>; Fri, 6 Nov 1998 10:14:47 +1100 Date: Fri, 6 Nov 1998 10:14:51 +1100 From: Peter Jeremy Subject: Re: Kernel threading (was Re: Thread Scheduler bug) To: current@FreeBSD.ORG Message-Id: <98Nov6.101447est.40365@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer writes: > easier to simply have a single pointer in a known address > that gets rewritten by the kernel on scheduling.. probably actually an > array of them, (one per cpu) with a 'getcpunumber()' to allow > the thread to work out which it should use. If I remember correctly, Sun have a per-CPU address space in Solaris kernel space (or maybe it was SunOS). I can't remember the exact size or address, but it went something like: 0xffe0000 - current CPU always mapped here 0xfffN000 - cpu N mapped here for all CPUs. This allows the kernel to have per-CPU data structures that can be readily accessed either for the CPU the thread is on, or for any other CPU. The CPU number could be a constant within the per-CPU space. A similar approach is possible for user space, but the cost of updating the PTEs may make it unacceptably expensive (as someone else mentioned). Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5247 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message