hugemem? smp?

[Rick Stevens]

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       -
----------------------------------------------------------------------