RE: compile problems

[prev] [thread] [next] [Date index for 2004/12/28]

Realized it just after I hit "send". 

Mail is moving rather quickly today...

> -----Original Message-----
> From: Stas Bekman [mailto:stas@xxxxxx.xxx] 
> Sent: Tuesday, December 28, 2004 4:48 PM
> To: Barksdale, Ray
> Subject: Re: compile problems
> 
> Ray, please followup to the list as a reply to that thread, 
> so others will 
> be able to learn from your mistakes. And we will take it from 
> there. Thanks.
> 
> Barksdale, Ray wrote:
> >>-----Original Message-----
> >>From: Stas Bekman [mailto:stas@xxxxxx.xxx] 
> >>Sent: Wednesday, December 22, 2004 6:02 PM
> >>To: Barksdale, Ray
> >>Cc: modperl@xxxx.xxxxxx.xxx
> >>Subject: Re: compile problems
> >>
> >>
> >>OK, so it has something to do with 64-bit-ness. But I didn't 
> >>understand. 
> >>Was this problem seen on a 64-bit CPU or on a 32-bit CPU, but 
> >>then code 
> >>was compiled for 64-bit?
> > 
> > 
> > The problem (more of an observation at this point) was the apparent
> > excessive memory usage of Apache2/mod_perl2 (64-bit build) on top
> > of 64-bit Linux (RedHat Fedora Core 2 - AMD64 distribution).
> > 
> > We built perl/Apache/mod_perl/libapreq/etc/etc.... in the 
> same fashion
> > as we had for our 32-bit environment (again RedHat Fedora 
> Core 2 - x86).
> > The memory load was normal.
> > We were not doing any crosscompiles of 64 to 32 or viceversa.
> > 
> > I had a brain fart. We (read "me") got crossed up on what 
> -m64 caused 
> > gcc to do. I read the docs and understood this to cause gcc 
> to force 
> > the usage of the additional registers on the opteron. This is the 
> > default behavior when building (note to self...) in the 
> 64-bit environment.
> > Also found that there is a -march=k8 option (again a 
> default in 64-bit
> > land).
> > 
> > As far as the memory usage problem I thought I was on to 
> the source when
> > I stripped my httpd binary and went from: 
> > 
> > 	VIRT	RES	SHR
> > 	76232 3856	73m
> >   to
> >   	17524 2064	15m
> > 
> > (both without mod_perl) but this resulted in a minimal gain once
> > mod_perl was loaded. 
> > 
> > I'll keep digging arround though.
> > 
> > 
> > 
> >>>On the bright side everything runs perfectly (in a bloated 
> >>
> >>sort of way ;)
> >>
> >>>Thanx a load.
> >>
> >>I didn't do anything :)
> > 
> > 
> > Well, for all my rootin' (as they say in Arkansas) I didn't 
> either :{
> > 
> > 
> > 
> >>
> >>-- 
> >>__________________________________________________________________
> >>Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
> >>http://stason.org/     mod_perl Guide ---> http://perl.apache.org
> >>mailto:stas@xxxxxx.xxx http://use.perl.org http://apacheweek.com
> >>http://modperlbook.org http://apache.org   http://ticketmaster.com
> >>
> > 
> > 
> > 
> > *****CONFIDENTIALITY NOTICE*****
> > This e-mail and any files or attachments may contain 
> confidential and
> > privileged information.  If you have received this message 
> in error, please
> > notify the sender at the above e-mail address and delete it 
> and all copies
> > from your system.
> > 
> 
> 
> -- 
> __________________________________________________________________
> Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/     mod_perl Guide ---> http://perl.apache.org
> mailto:stas@xxxxxx.xxx http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org   http://ticketmaster.com
> 


*****CONFIDENTIALITY NOTICE*****
This e-mail and any files or attachments may contain confidential and
privileged information.  If you have received this message in error, please
notify the sender at the above e-mail address and delete it and all copies
from your system.



        -- 
        Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html