hugemem? smp?

Rick Stevens rstevens at vitalstream.com
Fri Jul 21 21:44:25 UTC 2006


On Fri, 2006-07-21 at 13:37 -0700, Ron McKeever wrote:
> Oh... The first email said ES 3.0 servers... Sorry...
> 
> If the bios is out of date or messed up, linux can't get it's IRQs correct
> without the noapic.. 

Correct.  "noapic" tells the kernel to ignore what the BIOS did to the
APIC and to use its own code.

> Fyi...I have used noapic with 2.6 kernel also in regards to performance with
> video cards and then with clock speed (in our vmware GSX severs)...

Yup.

> 
> -----Original Message-----
> From: redhat-install-list-bounces at redhat.com
> [mailto:redhat-install-list-bounces at redhat.com] On Behalf Of Rick Stevens
> Sent: Friday, July 21, 2006 11:14 AM
> To: Getting started with Red Hat Linux
> Subject: RE: hugemem? smp?
> 
> On Fri, 2006-07-21 at 10:02 -0700, Ron McKeever wrote:
> > My 2 cents... I have seen if I don't use the noapic option, keventd takes
> up
> > a lot of cpu.
> > (on Redhat ES 3.0)
> 
> Yes, but that's a 2.4 kernel.  2.6 handles APICs better, and it may be
> that your BIOS programs it wrong in the first place.  "noapic" forces
> Linux to work around such issues.  Try updating your BIOS and trying
> it without "noapic" and see how it works.
> 
> > 
> > Ron
> > -----Original Message-----
> > From: redhat-install-list-bounces at redhat.com
> > [mailto:redhat-install-list-bounces at redhat.com] On Behalf Of Rick Stevens
> > Sent: Wednesday, July 19, 2006 2:35 PM
> > To: Getting started with Red Hat Linux
> > Subject: Re: hugemem? smp?
> > 
> > On Wed, 2006-07-19 at 15:04 -0700, chuck lawrence wrote:
> > > thanks to good-hearted folks here, I've been using the hugemem kernel to
> 
> > > address 8gb of ram on my dual opteron rh es 3.0 servers.
> > > 
> > > one user has reported that the cpu load balancing seems different on 
> > > these, compared to other servers with generic kernels (and less ram). 
> > > in particular, he says the hugemem systems pile more processes onto the 
> > > first processor, before moving on to the 2nd.
> > > 
> > > is hugemem multi-processor by default?  is there something else I should
> > do?
> > 
> > Yes, hugemem is multiprocessor.  The easiest way to check is:
> > 
> > 	# cat /proc/cpuinfo
> > 
> > You'll see multiple CPUs if you have multiple CPUs, hyperthreading CPUs
> > or multiple hyperthreading CPUs (essentially each hyperthread is treated
> > as a CPU).  So, a two-processor SMP machine with two standard Xeons
> > would show 4 CPUs.  A two-processor SMP, multicore, hyperthreading
> > machine would show 8 CPUs.
> > 
> > As to the load balancing...the memory model shouldn't cause a
> > significant difference.  CPU0 generally will be a bit busier since it
> > runs the scheduler.  If you don't use the APICs ("noapic" on the boot
> > command line), CPU0 will do almost all the I/O and it'll be busier
> > still.  The thing with smaller memory models is that you may end up
> > swapping more or doing more context switches and the differences between
> > the CPU loads can be masked by that.
> > 
> > ----------------------------------------------------------------------
> > - Rick Stevens, Senior Systems Engineer     rstevens at vitalstream.com -
> > - VitalStream, Inc.                       http://www.vitalstream.com -
> > -                                                                    -
> > -    "Hello. My PID is Inigo Montoya.  You `kill -9'-ed my parent    -
> > -                     process.  Prepare to vi."                      -
> > ----------------------------------------------------------------------
> > 
> > _______________________________________________
> > Redhat-install-list mailing list
> > Redhat-install-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/redhat-install-list
> > To Unsubscribe Go To ABOVE URL or send a message to:
> > redhat-install-list-request at redhat.com
> > Subject: unsubscribe
> > 
> > _______________________________________________
> > Redhat-install-list mailing list
> > Redhat-install-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/redhat-install-list
> > To Unsubscribe Go To ABOVE URL or send a message to:
> > redhat-install-list-request at redhat.com
> > Subject: unsubscribe
> ----------------------------------------------------------------------
> - Rick Stevens, Senior Systems Engineer     rstevens at vitalstream.com -
> - VitalStream, Inc.                       http://www.vitalstream.com -
> -                                                                    -
> -         Microsoft Windows:  Proof that P.T. Barnum was right       -
> ----------------------------------------------------------------------
> 
> _______________________________________________
> Redhat-install-list mailing list
> Redhat-install-list at redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-install-list
> To Unsubscribe Go To ABOVE URL or send a message to:
> redhat-install-list-request at redhat.com
> Subject: unsubscribe
> 
> _______________________________________________
> Redhat-install-list mailing list
> Redhat-install-list at redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-install-list
> To Unsubscribe Go To ABOVE URL or send a message to:
> redhat-install-list-request at redhat.com
> Subject: unsubscribe
----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer     rstevens at vitalstream.com -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
-  Silence!  Or I shall replace you with a very small shell script!  -
-                                                - The Wizard of OS  -
----------------------------------------------------------------------




More information about the Redhat-install-list mailing list