Date: Wed, 1 Jul 1998 23:39:17 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: imdave@mcs.net (Dave Bodenstab) Cc: hackers@FreeBSD.ORG, tlambert@primenet.com, freebsd-questions@FreeBSD.ORG, mkn@emailbox.hdtv.lucent.com Subject: Re: Unsupport calls Message-ID: <199807012339.QAA27019@usr07.primenet.com> In-Reply-To: <199807011642.LAA07192@base486.home.org> from "Dave Bodenstab" at Jul 1, 98 11:42:23 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > About the only serious one I can see is plock. Maybe somebody else on > > > the list can comment. > > From my old system 5 reference (when the OS used swapping rather than > paging): > > plock(2) - lock process, text, or data in memory > > #include <sys/lock.h> > int plock( int op ); > > Plock allows the calling process to lock its text segment, its > data segment, or both into memory. Locked segments are immue to > all routine swapping. Plock also allows these segments to > unlocked. The effective user ID of the calling process must be > super-user. OP is one of: > > PROCLOCK - lock text and data > TXTLOCK - lock text > DATLOCK - lock data > UNLOCK - remove locks I forgot this old saw. This was from back in SVR2, before the PMMU hit System V. I can see something being slightly faster because of this, but I think that rtprio will do some of it. Traditionally in BSD, this was handled on a per image basis, using the "sticky bit". Of course, the flip side is that by doing this for your process, you may be starving other processes of resources, causing them to thrash, and thereby consume more quantum. Which, of course, would result in you getting scheduled less often. Which would mean that your program wouldn't be faster. In general, this type of soloution, and things like fixed scheduling classes (which SVR4.2/UnixWare 2.x use to "protect" the interactive response of the X server -- the X server is guaranteed a fixed amount of the available quanta) are a kludge to deal with the fact that there aren't working-set quotas. The corresponding behaviour of the UnixWare 2.x X server is that the X server pages still gets thrashed out to disk by the linker, but the X sever burns a fair amount of your CPU thrashing them back in to guarantee that the mouse handling code is there when you wiggle your mouse. So while this may be missing from FreeBSD, it's not really a bad thing, I think (except that FreeBSD also lacks working-set quotas, which should be implemented as LRU page stealing from your own page list on a per vnode basis -- NOT vnodes being used as swap for executable pages! -- at a minimum). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807012339.QAA27019>