From owner-freebsd-arch Sat Jan 5 11:20:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 0DEC737B416 for ; Sat, 5 Jan 2002 11:20:09 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020105192008.NPKN288.rwcrmhc51.attbi.com@InterJet.elischer.org>; Sat, 5 Jan 2002 19:20:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA34122; Sat, 5 Jan 2002 11:17:59 -0800 (PST) Date: Sat, 5 Jan 2002 11:17:57 -0800 (PST) From: Julian Elischer To: Alfred Perlstein Cc: arch@freebsd.org Subject: Re: freeing thread structures. In-Reply-To: <20020104210829.T82406@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Fri, 4 Jan 2002, Alfred Perlstein wrote: > * Julian Elischer [020104 20:57] wrote: > > > > In mi_switch AFTER the switch to the new thread has been completed, > > (which is one possibility) the sched lock is held, so freeing any resource > > that wants to own a normal sleeping mutex would seem to be an instant > > panic. ANother possibility is to simply queue it for later freeing by > > another entity, but I REALLY would rather avoid having a reaper thread (or > > init) do it. > > Please just use a reaper thread for now, it will not stop you from > optimizing it later. Haven't we gone over this? Yes but there must be a good synchronous way of doing this.. An async method will always lead to a lag in teh number of threads actually available, as it will.... hmmmm I was going to say that the availability of threads will be limited because there will e actually free threads that have not yet been properly freed, by which I mean that they have not had their ucred's crfree()'d yet etc. However it just occurs to me that maybe if we ran short of threads, we are probably in a situation to free them and make them available to ourselves.. Possibly the answer is to have an async free-er PLUS the allocator can call the free-er if it looks like it's pool is empty. Maybe, on the other hand, just the allocator and a few other critical points may be enough on their own.. Say, the allocator, the entry point for the userland thread_exit(), and maybe some other place that will happen even if we are not doing those two things.. Probably in the upcall code.. The ready-to-free thread structureas don't have anything except for the ucred in them that really requires freeing before they are put into the thread cache. so it's not a lot of waste to let them gather up a bit... (They'd just be in the cache anyhow, unless it was full in which case the stackpages would be dissociated and freed) > > -Alfred > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message