From owner-freebsd-hackers Thu May 16 11:21:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA21852 for hackers-outgoing; Thu, 16 May 1996 11:21:16 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA21842; Thu, 16 May 1996 11:21:12 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA17487; Thu, 16 May 1996 11:18:36 -0700 From: Terry Lambert Message-Id: <199605161818.LAA17487@phaeton.artisoft.com> Subject: Re: A question for the VM gurus..! To: dyson@FreeBSD.ORG Date: Thu, 16 May 1996 11:18:35 -0700 (MST) Cc: rminnich@Sarnoff.COM, toor@dyson.iquest.net, jgreco@brasil.moneng.mei.com, hackers@FreeBSD.ORG In-Reply-To: <199605161424.JAA13589@dyson.iquest.net> from "John S. Dyson" at May 16, 96 09:24:08 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > MADV_WILLNEED appears to fault pages (again, asynchrnously, from > > > > what I can tell). > > > > > > Hmmm... time to implement kernel threads. > > > > actually, sunos had async. read-ahead from 1988 on, long before kernel > > threads. They just queued an i/o and did not wait for the result. So you > > don't absolutely have to have kernel threads. > > > We used to have async readahead in the VM system (vnode_pager.) It was a bit > tricky, and kernel threads might make it simpler. Maybe not? A kernel thread scheduled against a "work to do" queue would seem to be the correct way to handle async. But async wants to be more general than a simple implementation; it wants to be enough to implement async calls at user level. Rather than special casing the code in the read/write path to enable the aioread/aiowrite/aiowait/aiocancel, I'd like to see an alternate trap gate for async calls... much better for LWP support. So I guess the same changes needed for kernel multithreading would be needed regardless.... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.