Greg Stein wrote:
> On Wed, Mar 20, 2002 at 12:02:53PM +0800, Stas Bekman wrote:
> 
>>mod_perl child processes save a lot of memory when they can share memory 
>>with the parent process and quite often we get reports from people that 
>>they lose that shared memory when the system decides to page out the 
>>parent's memory pages because they are LRU (least recently used, the 
>>algorithm used by many memory managers). I believe that this applies to 
>>all httpd modules and httpd itself, the more we can share the less 
>>memory resources are needed, and usually it leads to a better performance.
>>
>>Therefore my question is there any reason for not using mlockall(2) in 
>>the parent process on systems that support it and when the parent httpd 
>>is started as root (mlock* works only within root owned processes).
>>
> 
> We don't really support httpd running as root. That is what that whole
> BIG_SECURITY_HOLE thing is about.

The parent process is always running as root if you want to bind to port 
80. And that's the only process that needs locking with mlockall().

We don't want any locking for child processes.

> If somebody is going to run as root, then let them put the mlockall() patch
> in themselves. Further, since mlockall() jams everything into memory, I'm
> wary of making this the default behavior [when running as root]. In turn,
> that means that we'd have to introduce a new directive to turn on the
> mlockall thing.
> 
> So the net result is: new behavior and a new directive to support a case
> (httpd running as root) that we don't even want/like people doing in the
> first place.

If this improves the httpd's performance what's so wrong with adding a 
new directive?

> I'd be a heavy -0 on such a thing.



-- 


_____________________________________________________________________
Stas Bekman             JAm_pH      --   Just Another mod_perl Hacker
http://stason.org/      mod_perl Guide   http://perl.apache.org/guide
mailto:[EMAIL PROTECTED]  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/

Reply via email to