Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Dec 2001 18:46:52 -0600
From:      Alfred Perlstein <bright@mu.org>
To:        Julian Elischer <julian@elischer.org>
Cc:        Julian Elischer <julian@vicor-nb.com>, arch@freebsd.org
Subject:   Re: Threads, KSEs etc. during exit.
Message-ID:  <20011212184652.C79896@elvis.mu.org>
In-Reply-To: <Pine.BSF.4.21.0112121541140.5654-100000@InterJet.elischer.org>; from julian@elischer.org on Wed, Dec 12, 2001 at 03:49:17PM -0800
References:  <20011212172324.V92148@elvis.mu.org> <Pine.BSF.4.21.0112121541140.5654-100000@InterJet.elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
* Julian Elischer <julian@elischer.org> [011212 18:00] wrote:
> 
> That's one of the possibilities I am considering, but you don't want to
> put too much extra testing etc on outgoing path of swtch() as it is called 
> a hell of a lot. It's also worth wondering if it's enough to store a
> single 'to be freed' thread in the pcpu area or whether we need an open
> ended scheme. The answer to that would depend on whether we could recurse
> before we had the chance to free what we alreay have there.

As I've said, it's more important to get it right than to make it
fast, we can make it fast later.  Why not just implement my solution?
it will be pleasantly simple.

> The freeing requires some "relatively complicated" things,
> e.g. freeing stack pages back to the vm, possibly freeing
> the vm-object associated with it, and maybe placing the thread structure
> back in the thread-zone for re-allocation. It is a question as to whether
> we may ever want to free the memory back to the system after
> a process with massive threading exits.

Yes, all valid points, but they have no bearing(sp?) without 
a working implementation.

-- 
-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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011212184652.C79896>