From owner-freebsd-arch Wed Dec 12 15:23:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 738DC37B416 for ; Wed, 12 Dec 2001 15:23:30 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 055DB81D01; Wed, 12 Dec 2001 17:23:25 -0600 (CST) Date: Wed, 12 Dec 2001 17:23:24 -0600 From: Alfred Perlstein To: Julian Elischer Cc: arch@freebsd.org Subject: Re: Threads, KSEs etc. during exit. Message-ID: <20011212172324.V92148@elvis.mu.org> References: <3C17DF99.1DE9D1A1@vicor-nb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C17DF99.1DE9D1A1@vicor-nb.com>; from julian@vicor-nb.com on Wed, Dec 12, 2001 at 02:52:09PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Julian Elischer [011212 16:52] wrote: > > Here is an implimentation detail I've hit that I'd like to > discuss because it has some ramifications for non KSE code too. [snip] > > This is all ok except that pmap_dispose_thread(td) will free > the stack pages so are we safe in returning? No. I think it's less important to get bogged down in the details, what would make more sense is to perform the cleanup as part of the job of the next-to-run thread's work as it exits the scheduler. This could be done in a MI fashion most likely. The only problem is possibly recursing into one of those subsystems in the case of thread pre-emption within the kernel. Ok, so let's make it a bit simpler. 1) The exiting thread marks the structures as "in use". 2) It then queues them on the end of a "to be freed" list, this needs a mutex. 3) It then enters the scheduler which runs the next thread. 4) On the way out in the context of another thread it will atomically mark the structures as "freeable" then issue a wakeup/cv_signal on the queue. 5) A dedicated per-cpu thread "thread_reaper" will then wakeup and perform the cleanup. Let's not over optimize it for now, getting it done correctly then optimizing will probably get the job done for now. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message