httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: performance: using mlock(2) on httpd parent process
Date Wed, 20 Mar 2002 19:49:50 GMT
On Wed, Mar 20, 2002 at 11:19:44AM -0800, Ian Holsman wrote:
> >FWIW, Solaris 8 introduced "priority paging", which basicly means
> >that pages that are non-executable will be swapped out earlier than
> >higher-priority executable pages. This of course introduces nasty little
> >tricks like marking a data file as executable just to ensure that it
> >gets priority paging.
> 
> priority paging is more to do with the filesystem cache than anything 
> else. in low memory conditions it start freeing pages used by the file 
> cache first. without it you could swap your machine to death by copying
> a 1 gig file around the place.

We are talking about a low memory condition, when the scanner is looking
for a page to swap out for whatever reason (including filesystem
activity). Before priority paging it would select a LRU page, which
could very likely be the program that is triggering the page fault.
With priority paging enabled, a non-executable page will be selected for
swapping before an executable one. Therefore the httpd binary will remain
in hard-wired memory longer than the anonymous pages it is operating on
(including the COW pages inherited in the children and any filesystem
cache pages).

Without priority paging an httpd process that required access to more
memory than physically present on the system could potentially cause
itself to be paged out and then immediate back in as soon as the next
instruction tripped a page fault. This would result in a huge amount
of thrashing, for even something as simple as copying a file (as
with your example).

So my point is we don't have to do mlock() on solaris8 (or 7 with p.p.
enabled) since we get similiar or sufficient behavior already.

-aaron


Mime
View raw message