Mandrake Linux Archives: cooker-amd64@linux-mandrake.com
Mandrake Linux: cooker-amd64@linux-mandrake.com
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
- From: John Scott
- Subject: Re: [cooker-amd64] Just curious
- Date: 13 Nov 2003 16:58:32 -0000
>>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On November 13, 2003 08:08 am, John Scott wrote: >>> > On Thu, Nov 13, 2003 at 08:04:09AM -0600, J.P. Pasnak wrote: >>> > > John Scott said: >>> > > > On Thu, Nov 13, 2003 at 07:52:52AM -0600, J.P. Pasnak wrote: >>> > > >> John Scott said: >>> > > >> > Hi all, yet another message from me! >>> > > >> > >>> > > >> > While I was checking a few things the other day on a Dual >>> > > >> > Opteron box, I ran the following command - >>> > > > >>> > > > Hmmmm, thought not! Just out of interest would you mind showing >>> > > > what the results of "cat /proc/irq/16/smp_affinity" are? >>> > > > >>> > > > I picked IRQ16, since that one seems completely balanced on your >>> > > > box. >>> > > >>> > > cat /proc/irq/16/smp_affinity >>> > > ffffffff >>> > > >>> > Hmmm, right so "ffffffff" pretty much means "balance" then? Most of >>> > mine are either set to "00000001" (running on CPU0) or "00000002" >>> > (running on CPU1).... >>> > >>> > Can I expect my machine to grind to a halt if I do a >>> > >>> > "echo ffffffff > /proc/irq/<whatever>/smp_affinity" >>> > >>> >>> I'd put money on 'yes' :) I did some searching, and it would appear >>> that 'noapic' will cause unbalanced interrupts, but it also says that >>> this in not necessarily a bad thing. >>> >>> - -- >> >> Hmmm that's interesting....currently that machine has a long running >> CPU intensive programming running which pretty much sits on CPU0 (it's >> been running about 2 weeks...about another 4-6 weeks runtime to go). >> >> It makes me wonder whether my machine is actually less "responsive" than >> it should be since the majority of the interrupts are also being handled >> by >> CPU0 with CPU1 pretty much sitting there not doing much (other than the >> odd few processes scheduled by the OS). >> > >Someone can correct me if I'm wrong, but a program can only take advantage >of two or more processors if the program itself has that capability (I >believe apache2 and quakeiii have smp support). However, if the kernel >is not allocating interrupts properly, all programs would be run on the >first processor. > >Ensuring you are running kernel-smp and removing 'noapic' from lilo might >help. >-- >Live fast, die young, >You're sucking up my bandwidth. >J.P. Pasnak, CD >CCNA >http://www.warpedsystems.sk.ca Well, no the program I'm talking about isn't multi-threaded but the OS will still schedule it between CPU's depending on system load. What is *actually* happening is that since the system is running quite minimally (i.e. no *intensive* processes other than my program) the OS scheduler pretty much leaves my long running program sitting on CPU0. I was just wondering whether the fact that all the interrupts are being handled by CPU0 too means that the systems isn't as "balanced" as it could be? Yep, it's an SMP kernel...hmm....I didn't pass any extra options when booting up so I *assume* that noapic hasn't been passed. Unfortunately I'll have to wait about another 4 weeks or so before I can reboot this box to check! Thanks, John.
- References:
- Re: [cooker-amd64] Just curious
- From: John Scott
- Re: [cooker-amd64] Just curious
- From: Gwenole Beauchesne
- Re: [cooker-amd64] Just curious
- From: John Scott
- Re: [cooker-amd64] Just curious
- From: John Scott
- Re: [cooker-amd64] Just curious
- Prev by Date: Re: [cooker-amd64] problem with autofs
- Next by Date: Re: FIXED! [cooker-amd64] NVidia drivers
- Previous by thread: Re: [cooker-amd64] Just curious
- Next by thread: Re: [cooker-amd64] Just curious
- Index(es):
