From owner-cvs-all Fri Nov 6 15:43:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA22913 for cvs-all-outgoing; Fri, 6 Nov 1998 15:43:53 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA22900 for ; Fri, 6 Nov 1998 15:43:44 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id PAA02131; Fri, 6 Nov 1998 15:43:27 -0800 (PST) (envelope-from dillon) Date: Fri, 6 Nov 1998 15:43:27 -0800 (PST) From: Matthew Dillon Message-Id: <199811062343.PAA02131@apollo.backplane.com> To: Tor.Egge@fast.no Cc: cvs-committers@FreeBSD.ORG Subject: Re: sendfile.2 (was Re: cvs commit: ...) References: <199811061936.LAA00920@apollo.backplane.com> <199811061957.UAA04029@midten.fast.no> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk : :> * critical state is stored on the supervisor stack. Not much of a :> disadvantage here either. : :What about UPAGES pageouts (e.g. pmap_swapout_proc()) ? We should not :store that kind of critical state in something that can be paged out. : :- Tor Egge Yah, I wasn't sure about how that worked. We could simply disable paging out of UPAGES in swapout while locks are present. It wouldn't cause any problems. If we keep track of the lock chain for the process, based at curproc->p_somenewfield, it would be easy to use the fact that the field is non-NULL to prevent a complete swapout from occuring. -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message