* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Alan Cox @ 2002-12-19 1:09 UTC (permalink / raw)
To: John Bradford
Cc: Larry McVoy, lm, alan, Linus Torvalds, davej, vonbrand,
Linux Kernel Mailing List, akpm
In-Reply-To: <200212182237.gBIMbQmk000479@darkstar.example.net>
On Wed, 2002-12-18 at 22:37, John Bradford wrote:
> I was trying to point out in an amusing way that a repeat of the BK
> flamewar we've seen on LKML was inappropriate.
I got the joke but I don't have a US postal address 8)
More seriously we have defect tracking now - > bugzilla.kernel.org
We have an advanced scalable groupware communication environment (email)
How the actual patches get applied really isnt relevant. I know Linus
hated jitterbug, Im guessing he hates bugzilla too ?
^ permalink raw reply
* Re: [Linux-ia64] installation help
From: Stephane Eranian @ 2002-12-19 0:21 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805612@msgid-missing>
Jane,
On Wed, Dec 18, 2002 at 04:14:44PM -0800, Jian Chen wrote:
>
> I installed ski and nue in order to use a cross
> compiler (open 64) from Intel on IA32. As I said, the
> binary did not work when I installed the compiler. Now
> that it works after running '/etc/rc.d/init.d/ia64fmt
> start'. Do I need to reinstall the compiler?
>
I would guess no. You would need to reinstall only if during the
installation of this compiler they need to run an IA-64 binary.
--
-Stephane
^ permalink raw reply
* Re: [PATCH][2.4] generic cluster APIC support for systems with more than 8 CPUs
From: Martin J. Bligh @ 2002-12-19 0:24 UTC (permalink / raw)
To: Pallipadi, Venkatesh, Linux Kernel
Cc: John Stultz, Nakajima, Jun, jamesclv, Mallick, Asit K,
Saxena, Sunil
In-Reply-To: <C8C38546F90ABF408A5961FC01FDBF1912E18E@fmsmsx405.fm.intel.com>
First thing, can you split this into much smaller pieces, each of
which perform one code change ... then it might be more feasible
to read it.
> - bool 'Multi-node NUMA system support' CONFIG_X86_NUMA
> - if [ "$CONFIG_X86_NUMA" = "y" ]; then
> + bool 'Clustered APIC (> 8 CPUs) support' CONFIG_X86_APIC_CLUSTER
> + if [ "$CONFIG_X86_APIC_CLUSTER" = "y" ]; then
> + define_bool CONFIG_X86_CLUSTERED_APIC y
> #Platform Choices
> bool ' Multiquad (IBM/Sequent) NUMAQ support' CONFIG_X86_NUMAQ
> if [ "$CONFIG_X86_NUMAQ" = "y" ]; then
> - define_bool CONFIG_X86_CLUSTERED_APIC y
> - define_bool CONFIG_MULTIQUAD y
> - fi
> - bool ' IBM x440 (Summit/EXA) support' CONFIG_X86_SUMMIT
> - if [ "$CONFIG_X86_SUMMIT" = "y" ]; then
> - define_bool CONFIG_X86_CLUSTERED_APIC y
> + define_bool CONFIG_MULTIQUAD y
You seem to have lost turning on CONFIG_X86_NUMA.
> --- linux-2.4.21-pre1.org/arch/i386/defconfig 2002-11-28 15:53:09.000000000 -0800
> +++ linux-test1/arch/i386/defconfig 2002-12-14 14:59:52.000000000 -0800
> @@ -62,6 +62,7 @@
> # CONFIG_MATH_EMULATION is not set
> # CONFIG_MTRR is not set
> CONFIG_SMP=y
> +CONFIG_X86_APIC_CLUSTER=y
> # CONFIG_MULTIQUAD is not set
> CONFIG_HAVE_DEC_LOCK=y
Errrm ... on by default?
> - if(clustered_apic_mode == CLUSTERED_APIC_XAPIC)
> - id = physical_to_logical_apicid(hard_smp_processor_id());
> + if(clustered_apic_mode)
> + id = cpu_2_logical_apicid[smp_processor_id()];
Don't use those arrays directly, use the macros.
And that was off before for NUMA-Q ... you seem to have turned it on.
Unless you've inverted the meaning of clustered_apic_mode, which is
going to confuse the hell out of everyone?
> - if (clustered_apic_mode != CLUSTERED_APIC_NUMAQ) {
> + if (configured_platform_type != CONFIGURED_PLATFORM_NUMA) {
OK, what exactly are your switching rules here? Before:
if (clustered_apic_mode == CLUSTERED_APIC_NUMAQ) -> numaq only
if (clustered_apic_mode == CLUSTERED_APIC_XAPIC) -> x440
if (clustered_apic_mode) -> numaq or x440
Make sure you match that switching logic in whatever you do.
For instance, this whole section gets skipped for NUMA-Q, but not
other NUMA machines.
> /* Multi-Quad has an extended PCI Conf1 */
> - if(clustered_apic_mode == CLUSTERED_APIC_NUMAQ)
> + if(configured_platform_type == CONFIGURED_PLATFORM_NUMA)
If that's the direct substitution you're trying to make, don't misname
NUMAQ stuff as NUMA - very confusing ...
OK ... I give up trying to read the rest of it until you explain the
switching rules you're trying to use ... perhaps they're just confusingly
named, but it looks all wrong to me ...
M.
^ permalink raw reply
* Re: 2.4.19, don't "hdparm -I /dev/hde" if hde is on a Asus A7V133 Promise ctrlr, or...
From: Alan Cox @ 2002-12-19 1:11 UTC (permalink / raw)
To: D.A.M. Revok; +Cc: Linux Kernel Mailing List, support
In-Reply-To: <200212181703.18647.marvin@synapse.net>
On Wed, 2002-12-18 at 22:03, D.A.M. Revok wrote:
> Then I'm not buying Promise from now on. Period.
>
> Being non-able to both
> boot-from-SCSI-CDR, and
> use smartctl
> is non-acceptable, and if their NDAs rig that then they are a threat
> against /everything/ I base on my systems.
>
> Promise, your business-model damages your customer-relationship's
> survival, are you listening
Those kind of NDA's are quite normal. You'll see them elsewhere too. You
get this maze of NDA's between vendors about hardware flaws. So promise
might do a workaround for an ibm disk but have NDA's with IBM that says
they can't tell people. (Thats an example I'm not saying there is a real
IBM case)
Ditto with AGP and AMD for example. They have magic fixup registers for
timings, but won't tell us the fixups for various vendors cards (which
is dumb because its not hard to find out in windows!)
^ permalink raw reply
* Re: get_pteptr mystery
From: Paul Mackerras @ 2002-12-19 0:23 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: devel list
In-Reply-To: <1040256384.30597.70.camel@granite.austin.ibm.com>
Hollis Blanchard writes:
> I need to mark the first kernel code page writeable because I need to
> write to 0xc00000fc. Can someone tell me why the following code fails?
> get_pteptr returns 0.
What platform, what tree? :)
Paul.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* cmpci: microphone/line in not working
From: Pierre-Marc Fournier @ 2002-12-19 0:31 UTC (permalink / raw)
To: linux-kernel
Hello, my microphone does not work with my c-media CM8738 (builtin in
asus a7v333 motherboard).
Using kernel 2.4.18
Adjusted mixer properties so that the recording input is the microphone.
Volume is at max for microphone (play and record). No hardware mute on
the microphone. I should be hearing the mike in the speakers without
even recording, right?
Recording gives no error, but only silence is recorded.
Used gnome-sound-recorder for the tests
Everything works fine on other OS with exact same hardware
configuration.
The cmpci v.5.64 gave me this error, while trying to record I think, but
it does not do so at every attempt.
cmpci: read: chip lockup? dmasz 65536 fragsz 256 count 0 hwptr 0 swptr 0
Tried latest: v.5.68; didn't give the error but I'm not sure it won't
ever since I'm not able to reproduce it on v.5.64 (It just happens
sometimes.)
Here's the startup output. Apart from the error, there are no other
messages from the driver. 5.64 output is basically the same.
cm: version $Revision: 5.68 $ time 18:26:47 Dec 18 2002
PCI: Found IRQ 10 for device 00:05.0
PCI: Sharing IRQ 10 with 00:09.2
cm: found CM8738 adapter at io 0xb800 irq 10
chip version = 055
cm: Enable SPDIF loop
Audio output works perfectly.
Any help appreciated.
Thanks
Pierre
^ permalink raw reply
* Re: [parisc-linux] still problems with PCI IDE controller
From: Alan Cox @ 2002-12-19 1:06 UTC (permalink / raw)
To: Joerg Steindlberger; +Cc: Grant Grundler, parisc-linux
In-Reply-To: <courier.3E00F419.0000601B@server01>
On Wed, 2002-12-18 at 22:18, Joerg Steindlberger wrote:
> Okay. I now set hdparm -c 1 /dev/... and hdparm -d 1 /dev/... -- before
> starting the softwareRAID. The RAID1 is syncing this moment with about 2
> Mbyte/s. I think I'll stop it now and mount the shorter 80pin cable again and
> play with some speed settings. My earlier problem with DMA was, that the
> kernal crashed when setting the CONFIG_IDEDMA_AUTO=y.
> > Nope. IDE is EEEeevil ;^)
> Yes, I know. But what would You pay for two 80 GB disks?
To be fair PIO IDE is evil but UDMA is pretty nice. The big thing
lacking which is slowly coming is TCQ. Given TCQ and SATA hotswap (which
we dont handle at all yet) SCSI is I think rather doomed on the low end.
Alan
^ permalink raw reply
* Re: Linux 2.4.21-pre2
From: Alan Cox @ 2002-12-19 1:16 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Marcelo Tosatti, mikael.starvik, lkml
In-Reply-To: <20021218233146.A2399@infradead.org>
On Wed, 2002-12-18 at 23:31, Christoph Hellwig wrote:
> > <mikael.starvik@axis.com>:
> > o CRIS architecture update for 2.4.21
>
> This seems to include some strange stuff.
>
> It reverts the s/extern __inline__/static __inline__/g changes
> in include/asm-cris/ and adds a junk file in
> arch/cris/drivers/bluetooth/bt.patch
Dunno where the junk came from. I'll review the other one - its from me
not from Axis, although if Axis would glance over and fixup the ide bits
that would be great as its not a platform I have access too
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Russell King @ 2002-12-19 0:37 UTC (permalink / raw)
To: Alan Cox; +Cc: Linux Kernel Mailing List
In-Reply-To: <1040260157.26882.7.camel@irongate.swansea.linux.org.uk>
On Thu, Dec 19, 2002 at 01:09:17AM +0000, Alan Cox wrote:
> How the actual patches get applied really isnt relevant. I know Linus
> hated jitterbug, Im guessing he hates bugzilla too ?
I'm waiting for the kernel bugzilla to become useful - currently the
record for me has been:
3 bugs total
3 bugs for serial code for drivers I don't maintain, reassigned to mbligh.
This means I write (choose one):
1. non-buggy code (highly unlikely)
2. code no one tests
3. code people do test but report via other means (eg, email, irc)
If it's (3), which it seems to be, it means that bugzilla is failing to
do its job properly, which is most unfortunate.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Larry McVoy @ 2002-12-19 0:37 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
In-Reply-To: <200212190018.gBJ0Iir04816@devserv.devel.redhat.com>
On Wed, Dec 18, 2002 at 07:18:44PM -0500, Alan Cox wrote:
> > > > I can understand it when we're discussing BK; other than that, it's pretty
> > > > friggin lame. If that's what was behind your posts, Alan, there is an
> > > > easy procmail fix for that.
> > >
> > > It wasnt me who brought up bitkeeper
> >
> > PLONK. Into kernel-spam you go. I've had it with ax grinders.
>
> Oh dear me. Larry McVoy has flipped
>
> I'm now being added to his spam list for *not* mentioning bitkeeper
>
> Poor Larry, I hope has a nice christmas break, he clearly needs it
Look, Alan and anyone else, I'm sort of sick of the flames about BK.
It's apparent that there will always be people who are looking for
excuses to attack BK because it isn't GPLed and how dare the kernel
hackers use it. Your mail was so senseless that that was the only sane
explanation I could find and apparently I wasn't being paranoid, that's
what John thought as well.
I have a bad habit of taking things personally and too seriously and
the result is that attacks on me/BK/whatever, imagined or real, stress
me out and waste my time. Life's too short to for me to deal with that
nonsense anymore. I discovered procmail and I dump people into a spam
file if I feel they have a track record of yanking my chain. It's my
fault that I'm such a wuss that I can't handle it but this works.
It's not personal, it's about having a more pleasant life and I find
things to be more pleasant without the flames.
I'll still read your mail, I do so about every 2 weeks, but that way
whatever yankage you were (or were not) trying to do is in the past and
I'll ignore it.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: John Bradford @ 2002-12-19 0:53 UTC (permalink / raw)
To: Alan Cox; +Cc: lm, torvalds, davej, vonbrand, linux-kernel, akpm
In-Reply-To: <200212190008.gBJ08vw02314@devserv.devel.redhat.com>
> > I don't understand why BK is part of the conversation. It has nothing to
> > do with it. If every time I post to this list the assumption is that it's
> > "time to beat larry up about BK" then it's time for me to get off the list.
> >
> > I can understand it when we're discussing BK; other than that, it's pretty
> > friggin lame. If that's what was behind your posts, Alan, there is an
> > easy procmail fix for that.
>
> It wasnt me who brought up bitkeeper
>
No, it's my fault - I was skimming through list traffic, and not
concentrating, (proof of this is the fact that I've had sendmail
configured incorrectly all day, and been posting from the wrong
address, and only just realised :-) ).
I saw Larry mention kernel.bkbits.net, and Alan say, "We've got one -
its called linux-kernel", (in a separate message without quoting
anything, so it's really your fault :-) :-) :-) ), and assumed that a
BK argument was imminent, and I made a joke comment that it, (an
argument), was not a 2.6 required feature.
Sorry about the wasted bandwidth, I'll stop posting as it's now past
midnight, and I obviously need sleep.
Oh, 2.4.20-pre2 compiled OK for me, I hope that proves I've done
something useful tonight.
John.
^ permalink raw reply
* Re: [BUG] module-init-tools 0.9.3, rmmod modules with '-'
From: Rusty Russell @ 2002-12-19 0:39 UTC (permalink / raw)
To: Kai Germaschewski; +Cc: vamsi, Zwane Mwaikambo, lkml
In-Reply-To: <Pine.LNX.4.44.0212181144120.21707-100000@chaos.physics.uiowa.edu>
In message <Pine.LNX.4.44.0212181144120.21707-100000@chaos.physics.uiowa.edu> y
ou write:
> On Wed, 18 Dec 2002, Rusty Russell wrote:
> > Has there ever been a simple way?
>
> Well, you can do
>
> cd my_module
> echo "obj-m := my_module.o" > Makefile
> vi my_module.c
> make -C <path/to/kernel/src> SUBDIRS=$PWD modules
>
> That's not too bad (and basically works for 2.4 as well)
And then you're independent of changes in the build system, too. I
like it.
Thanks for the tip!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply
* 15000+ processes -- poor performance ?!
From: Till Immanuel Patzschke @ 2002-12-19 0:46 UTC (permalink / raw)
To: lse-tech; +Cc: linux-kernel@vger.kernel.org
Dear List(s),
as part of my project I need to run a very high number of processes/threads on a
linux machine. Right now I have a Dual-PIII 1.4G w/ 8GB RAM -- I am running
4000 processes w/ 2-3 threads each totaling in a process count of 15000+
processes (since Linux doesn't really distinguish between threads and
processes...).
Once I pass the 10000 (+/-) pocesses load increases drastically (on startup,
although it returns to normal), however the system time (on one processor)
reaches for 54% (12061 procs) while the only non sleeping process is top -- the
system is basically doing nothing (except scheduling the "nothing" which
consumes significant system time).
Is there anything I can do to reduce that system load/time? (I haven't been
able to exactly define the "line" but it definitly gets worse the more processes
need to be handled.)
Does any of the patchsets address this particular problem?
BTW: The processes are all alike...
Thanks for you help!
Immanuel
^ permalink raw reply
* RE: [PATCH 2.5.52] Use __set_current_state() instead of current-> state = (take 1)
From: Perez-Gonzalez, Inaky @ 2002-12-19 0:46 UTC (permalink / raw)
To: 'Robert Love'; +Cc: torvalds, linux-kernel
> > In fs/*.c, many functions manually set the task state directly
> > accessing current->state, or with a macro, kind of
> > inconsistently. This patch changes all of them to use
> > [__]set_current_state().
>
> Some of these should probably be set_current_state(). I
> realize the current code is equivalent to __set_current_state()
> but it might as well be done right.
Agreed; however, I also don't want to introduce unnecessary
bloat, so I need to understand first what cases need it - it
is kind of hard for me. Care to let me know some gotchas?
> > - current->state = TASK_INTERRUPTIBLE;
> > + __set_current_state (TASK_INTERRUPTIBLE);
> > add_wait_queue(fl_wait, &wait);
> > if (timeout == 0)
>
> At least this guy should be set_current_state(), on quick glance.
Is that because it is called lockless? ... grunt, in some areas
is kind of very obscure to guess if it is or not.
Inaky Perez-Gonzalez -- Not speaking for Intel - opinions are my own [or my
fault]
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: John Bradford @ 2002-12-19 0:59 UTC (permalink / raw)
To: Alan Cox; +Cc: lm, lm, torvalds, davej, vonbrand, linux-kernel, akpm
In-Reply-To: <1040260157.26882.7.camel@irongate.swansea.linux.org.uk>
> > I was trying to point out in an amusing way that a repeat of the BK
> > flamewar we've seen on LKML was inappropriate.
>
> I got the joke but I don't have a US postal address 8)
Eh??? US postal address? What!? Now I am really confused.
> More seriously we have defect tracking now - > bugzilla.kernel.org
> We have an advanced scalable groupware communication environment (email)
>
> How the actual patches get applied really isnt relevant. I know Linus
> hated jitterbug, Im guessing he hates bugzilla too ?
I don't like bugzilla particularly, it's too clunky, and it's
difficult to check that you are not entering a duplicate bug when the
database gets too big. Maybe that's just my opinion, though. Maybe I
should write a better bug tracking system...
John.
^ permalink raw reply
* Re: get_pteptr mystery
From: Hollis Blanchard @ 2002-12-19 0:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: devel list
In-Reply-To: <15873.4495.363395.683328@argo.ozlabs.ibm.com>
On Wed, 2002-12-18 at 18:23, Paul Mackerras wrote:
> Hollis Blanchard writes:
>
> > I need to mark the first kernel code page writeable because I need to
> > write to 0xc00000fc. Can someone tell me why the following code fails?
> > get_pteptr returns 0.
>
> What platform, what tree? :)
Right, sorry. linuxppc_2_4_devel running on a 405LP (Beech board).
-Hollis
--
PowerPC Linux
IBM Linux Technology Center
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: 15000+ processes -- poor performance ?!
From: Till Immanuel Patzschke @ 2002-12-19 0:53 UTC (permalink / raw)
To: lse-tech, linux-kernel@vger.kernel.org
In-Reply-To: <3E0116D6.35CA202A@inw.de>
forgot the kernel version (2.4.20aa1)...
Till Immanuel Patzschke wrote:
> Dear List(s),
>
> as part of my project I need to run a very high number of processes/threads on a
> linux machine. Right now I have a Dual-PIII 1.4G w/ 8GB RAM -- I am running
> 4000 processes w/ 2-3 threads each totaling in a process count of 15000+
> processes (since Linux doesn't really distinguish between threads and
> processes...).
> Once I pass the 10000 (+/-) pocesses load increases drastically (on startup,
> although it returns to normal), however the system time (on one processor)
> reaches for 54% (12061 procs) while the only non sleeping process is top -- the
> system is basically doing nothing (except scheduling the "nothing" which
> consumes significant system time).
> Is there anything I can do to reduce that system load/time? (I haven't been
> able to exactly define the "line" but it definitly gets worse the more processes
> need to be handled.)
> Does any of the patchsets address this particular problem?
> BTW: The processes are all alike...
>
> Thanks for you help!
>
> Immanuel
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [Lse-tech] 15000+ processes -- poor performance ?!
From: Martin J. Bligh @ 2002-12-19 0:47 UTC (permalink / raw)
To: Till Immanuel Patzschke, lse-tech; +Cc: linux-kernel@vger.kernel.org
In-Reply-To: <3E0116D6.35CA202A@inw.de>
> as part of my project I need to run a very high number of processes/threads on a
> linux machine. Right now I have a Dual-PIII 1.4G w/ 8GB RAM -- I am running
> 4000 processes w/ 2-3 threads each totaling in a process count of 15000+
> processes (since Linux doesn't really distinguish between threads and
> processes...).
> Once I pass the 10000 (+/-) pocesses load increases drastically (on startup,
> although it returns to normal), however the system time (on one processor)
> reaches for 54% (12061 procs) while the only non sleeping process is top -- the
> system is basically doing nothing (except scheduling the "nothing" which
> consumes significant system time).
> Is there anything I can do to reduce that system load/time? (I haven't been
> able to exactly define the "line" but it definitly gets worse the more processes
> need to be handled.)
You don't even specify what kernel you're using ...
> Does any of the patchsets address this particular problem?
Read the linux-kernel archives.
M.
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Jeff Garzik @ 2002-12-19 0:58 UTC (permalink / raw)
To: Alan Cox, Linux Kernel Mailing List
In-Reply-To: <20021219003740.C20566@flint.arm.linux.org.uk>
On Thu, Dec 19, 2002 at 12:37:40AM +0000, Russell King wrote:
> This means I write (choose one):
> 3. code people do test but report via other means (eg, email, irc)
> If it's (3), which it seems to be, it means that bugzilla is failing to
> do its job properly, which is most unfortunate.
Given that it started around Halloween, I would at least give it a
chance before claiming its failure. :)
IMO Bugzilla is gonna become even more useful as the code freeze hits,
and there are bugs we want to track until we get around to fixing
them...
Jeff
^ permalink raw reply
* [parisc-linux] rp2430 questions
From: Gavin Hubbard @ 2002-12-19 0:51 UTC (permalink / raw)
To: parisc-linux
Hi
I'm installing a dual-boot rp2430 system for one of our developers this weekend. Are there any parisc-linux issues I need to be aware of with regards to the crippled firmware e.g. known installation problems or gotchas?
Also, if we do a firmware upgrade to rp2470 in two or three months time will it require a complete rebuild or reinstallation of the linux OE to support the unlocked hardware?
Regards,
Gavin
^ permalink raw reply
* Re: 15000+ processes -- poor performance ?!
From: Jeff Garzik @ 2002-12-19 0:59 UTC (permalink / raw)
To: Till Immanuel Patzschke; +Cc: lse-tech, linux-kernel@vger.kernel.org
In-Reply-To: <3E0116D6.35CA202A@inw.de>
On Wed, Dec 18, 2002 at 04:46:15PM -0800, Till Immanuel Patzschke wrote:
> Dear List(s),
>
> as part of my project I need to run a very high number of processes/threads on a
> linux machine. Right now I have a Dual-PIII 1.4G w/ 8GB RAM -- I am running
> 4000 processes w/ 2-3 threads each totaling in a process count of 15000+
> processes (since Linux doesn't really distinguish between threads and
> processes...).
> Once I pass the 10000 (+/-) pocesses load increases drastically (on startup,
> although it returns to normal), however the system time (on one processor)
> reaches for 54% (12061 procs) while the only non sleeping process is top -- the
> system is basically doing nothing (except scheduling the "nothing" which
> consumes significant system time).
> Is there anything I can do to reduce that system load/time? (I haven't been
> able to exactly define the "line" but it definitly gets worse the more processes
> need to be handled.)
Redesign your program to not do silly things like this.
Unless you have hardware with 5000 or more CPUs...
Jeff
^ permalink raw reply
* RE: [PATCH 2.5.52] Use __set_current_state() instead of current-> state = (take 1)
From: Robert Love @ 2002-12-19 1:03 UTC (permalink / raw)
To: Perez-Gonzalez, Inaky; +Cc: torvalds, linux-kernel
In-Reply-To: <A46BBDB345A7D5118EC90002A5072C7806CACA2A@orsmsx116.jf.intel.com>
On Wed, 2002-12-18 at 19:46, Perez-Gonzalez, Inaky wrote:
> > Some of these should probably be set_current_state(). I
> > realize the current code is equivalent to __set_current_state()
> > but it might as well be done right.
>
> Agreed; however, I also don't want to introduce unnecessary
> bloat, so I need to understand first what cases need it - it
> is kind of hard for me. Care to let me know some gotchas?
set_current_state() includes a write barrier to ensure the setting of
the state is flushed before any further instructions. This is to
provide a memory barrier for weak-ordering processors that can and will
rearrange the writes.
Not all processors like those made by your employer are strongly-ordered
:)
Anyhow, the problem is when the setting of the state is set to
TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE. In those cases, it may be
possible for the state to actually be flushed to memory AFTER the wake
up event has occurred.
So you have code like this:
__set_current_state(TASK_INTERRUPTIBLE);
add_waitqueue(...);
but the processor ends up storing the current->state write after the
task is added to the waitqueue. In between those events, the wake up
event occurs and the task is woken up. Then the write to current->state
is flushed. So you end up with:
add_waitqueue(...);
interrupt or whatever occurs and wakes up the wait queue
task is now woken up and running
current->state = TASK_INTERRUPTIBLE /* BOOM! */
the task is marked sleeping now, but its wait event has already occurred
-- its in for a long sleep...
So to ensure the write is flushed then and there, and that the processor
(or compile, but we do not really worry about it because the call to
add_waitqueue will act as a compiler barrier, for example) does not move
the write to after the potential wake up, we use the write barrier.
In short, set_current_state() uses a memory barrier to ensure the state
setting occurs before any potential wake up activity, eliminating a
potential race and process deadlock.
It sounds complicated but its pretty simple... my explanation was
probably way too long - better than any I have seen here before on why
we have these things, at least. Hope it helps.
If in doubt, just make all of them set_current_state(). That is the
standard API, and its at least safe.
Robert Love
^ permalink raw reply
* RE: 15000+ processes -- poor performance ?!
From: Perez-Gonzalez, Inaky @ 2002-12-19 1:04 UTC (permalink / raw)
To: 'Till Immanuel Patzschke', lse-tech, linux-kernel
>
> forgot the kernel version (2.4.20aa1)...
You need the O(1) scheduler; not sure if aa has it or not; if not, lots of
processes will suck your machine. I think -ac has the O(1) scheduler, or try
2.5. The old scheduler is pretty cool but not as scalable as the new one.
If it has it ... well, I have no idea - maybe Robert Love would know.
Inaky Perez-Gonzalez -- Not speaking for Intel - opinions are my own [or my
fault]
^ permalink raw reply
* RE: [PATCH][2.4] generic cluster APIC support for systems with more than 8 CPUs
From: Pallipadi, Venkatesh @ 2002-12-19 1:05 UTC (permalink / raw)
To: Linux Kernel, Christoph Hellwig
Cc: Martin Bligh, John Stultz, Nakajima, Jun, jamesclv,
Mallick, Asit K, Saxena, Sunil
I have started working on a similar patch for 2.5. Other thing in my todo list is to
split this patch up into chunks.
Other comments inlined below.
> From: Christoph Hellwig [mailto:hch@infradead.org]
> On Wed, Dec 18, 2002 at 02:36:20PM -0800, Pallipadi, Venkatesh wrote:
> > xAPIC support can actually be determined from the LAPIC version.
>
> Are you sure? IIRC some of the early summit boxens didn't report the
> right versions..
> does this really not break anything in the fragile summit setups?
I am not really sure about the local APIC versions in summit. What I remember seeing on
lkml was summit has older IOAPIC version. Can someone clarify this?
> Okay, this was wrong before, but any chance you could use proper
> style here (i.e. if ()
> Again.
oops.. I somehow missed these 'if' coding style stuff. changing it immediately.
> > + define_bool CONFIG_X86_CLUSTERED_APIC y
> Do we really need CONFIG_X86_APIC_CLUSTER _and_ CONFIG_X86_CLUSTERED_APIC?
I will also eliminate CONFIG_X86_APIC_CLUSTER and use CONFIG_X86_CLUSTERED_APIC directly.
>
> - if (clustered_apic_mode == CLUSTERED_APIC_NUMAQ) {
> + if (clustered_apic_mode &&
> + (configured_platform_type ==
> CONFIGURED_PLATFORM_NUMA) ) {
>
> Doesn;t configured_platform_type == CONFIGURED_PLATFORM_NUMA imply
> clustered_apic_mode? and it should be at least
> CONFIGURED_PLATFORM_NUMAQ,
> btw. Probably better something short like SUBARCH_NUMAQ..
Yes, right now CONFIGURED_PLATFORM_NUMA implies clustered_apic_mode, and one of the
checks in the above 'if' is redundant. Will do a search and replace of NUMA by NUMAQ.
Thanks,
Venkatesh
^ permalink raw reply
* Re: [BUGlet] security/Kconfig
From: Greg KH @ 2002-12-19 1:04 UTC (permalink / raw)
To: Philipp Matthias Hahn, Kernel Mailing List
In-Reply-To: <20021217151507.GA21929@walker.pmhahn.de>
On Tue, Dec 17, 2002 at 04:15:07PM +0100, Philipp Matthias Hahn wrote:
> Hi!
>
> It was and is still strange when reading this, but
Thanks, I think the patch I just sent to the list and Linus should help
clear the confusion up about this module. If not, please let me know.
thanks,
greg k-h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.