From owner-freebsd-arch Thu Dec 13 3:20:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 022B037B416 for ; Thu, 13 Dec 2001 03:20:20 -0800 (PST) Received: (qmail 31893 invoked from network); 13 Dec 2001 11:20:18 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 13 Dec 2001 11:20:18 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20011212172324.V92148@elvis.mu.org> Date: Thu, 13 Dec 2001 03:20:13 -0800 (PST) From: John Baldwin To: Alfred Perlstein Subject: Re: Threads, KSEs etc. during exit. Cc: arch@freebsd.org, Julian Elischer 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 On 12-Dec-01 Alfred Perlstein wrote: > * 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. Have one thread reaper kproc for now. Eventually I think we will want a generic mechanism for specifying that a given kproc should have per-cpu threads and we can worry about that later. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message