* RE: 15000+ processes -- poor performance ?!
From: Alan Cox @ 2002-12-19 2:31 UTC (permalink / raw)
To: Perez-Gonzalez, Inaky
Cc: 'Till Immanuel Patzschke', lse-tech,
Linux Kernel Mailing List
In-Reply-To: <A46BBDB345A7D5118EC90002A5072C7806CACA2C@orsmsx116.jf.intel.com>
On Thu, 2002-12-19 at 01:04, Perez-Gonzalez, Inaky wrote:
>
> >
> > 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.
He's running the -aa kernel, which has all the right bits for this too.
In fact in some ways for very large memory boxes its probably the better
variant
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Martin J. Bligh @ 2002-12-19 1:43 UTC (permalink / raw)
To: Russell King, Alan Cox; +Cc: Linux Kernel Mailing List
In-Reply-To: <20021219003740.C20566@flint.arm.linux.org.uk>
> 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.
Not everyone will end up using it ... if people want to log bugs from
lkml into bugzilla, I think that'd help gather a critical mass.
Are you getting a lot of bug-reports for serial code on lkml? I use it
heavily, and it seems to work just fine to me .... so I pick (1). Yay! ;-)
Some of the bugs in there lie fallow, but I've seen quite a few get fixed.
The fact that some people (Dave Jones springs to mind) trawl through there
being extremely helpful fixing things is very useful ;-) Lots of things got
fixed, though I can't *prove* it was solely due to it being in Bugzilla.
As the list of bugs increases, it'll become an increasingly powerful
search engine for information as well .... I'll draw up a list of things
that don't seem to being worked on, and mail it out to kernel-janitors
and/or lkml and see if people are interested in fixing some of the fallow
stuff.
M.
^ permalink raw reply
* Re: 15000+ processes -- poor performance ?!
From: Robert Love @ 2002-12-19 1:42 UTC (permalink / raw)
To: David Lang
Cc: William Lee Irwin III, Till Immanuel Patzschke, lse-tech,
linux-kernel@vger.kernel.org
In-Reply-To: <Pine.LNX.4.44.0212181717510.7848-100000@dlang.diginsite.com>
On Wed, 2002-12-18 at 20:20, David Lang wrote:
> Ok, I wasn't sure of the cause, but I've seen this as far back as 2.2 I
> had a machine trying to run 2000 processes under 2.2 and 2.4.0 (after
> upping the 2.2 kernel limit) and top would cost me ~40% throughput on the
> machine (while claiming it was useing ~5% of the CPU)
Yah a lot of it is like William is saying... you just do not want to
read multiple files for each process in /proc when you have a kajillion
processes, and that is what top does. Over and over.
Work has gone into 2.5 to make this a lot better.. If you use threads
with NPTL in 2.5, a lot of this is resolved, since the sub-threads will
not show up in as /proc/#/ entries.
Robert Love
^ permalink raw reply
* Re: [BENCHMARK] scheduler tunables with contest - max_timeslice
From: Robert Love @ 2002-12-19 1:40 UTC (permalink / raw)
To: Con Kolivas; +Cc: linux kernel mailing list, Ingo Molnar
In-Reply-To: <1040261508.3e012184e56c4@kolivas.net>
On Wed, 2002-12-18 at 20:31, Con Kolivas wrote:
> Using the osdl (http://www.osdl.org) resources provided to me I'm running a
> series of contest benchmarks on 2.5.52-mm1 and modifying the scheduler tunables
> as provided by RML's patch. SMP used to minimise how long it will take me to do
> these. This is the first in the series and I've run a range of max_timeslices
> (default is 300ms; range 100-400):
Thanks, Con.
> I will continue to do these with some of the other scheduler tunables. I will
> need recommendations if anyone is interested in further resolution testing than
> that I'm currently doing.
Some ideas...
Try child_penalty=50,75 (default is 95%)
Try max_sleep_avg=500,1000,4000 (default is 2000ms)
Try prio_bonus_ratio=0,10,30,50 (default is 25%)
Try starvation_limit=1000 (default is 2000ms)
Some of these are just academic, although I am curious about
child_penalty and starvation_limit. In other cases, we can assuredly
improve interactivity but we have to worry about throughput and
starvation. Nonetheless, I am curious as to what you will find. :)
Robert Love
^ permalink raw reply
* Re: 15000+ processes -- poor performance ?!
From: William Lee Irwin III @ 2002-12-19 1:36 UTC (permalink / raw)
To: David Lang
Cc: Till Immanuel Patzschke, lse-tech, linux-kernel@vger.kernel.org
In-Reply-To: <Pine.LNX.4.44.0212181717510.7848-100000@dlang.diginsite.com>
On Wed, Dec 18, 2002 at 05:20:02PM -0800, David Lang wrote:
> Ok, I wasn't sure of the cause, but I've seen this as far back as 2.2 I
> had a machine trying to run 2000 processes under 2.2 and 2.4.0 (after
> upping the 2.2 kernel limit) and top would cost me ~40% throughput on the
> machine (while claiming it was useing ~5% of the CPU)
> David Lang
It wasn't really lying to you. The issue is that the kernel samples at
regular intervals to avoid timer reprogramming overhead. Now top(1) is
isochronous in nature as it's trying to periodically refresh, and so
it runs in lockstep with the clock interrupt, and the kernel hands back
bad numbers to top(1).
Bill
^ permalink raw reply
* Re: [parisc-linux] rp2430 questions
From: Grant Grundler @ 2002-12-19 1:29 UTC (permalink / raw)
To: Gavin Hubbard; +Cc: parisc-linux
In-Reply-To: <20021219005118.LJTP14518.web4-rme.xtra.co.nz@[127.0.0.1]>
On Thu, Dec 19, 2002 at 01:51:18PM +1300, Gavin Hubbard wrote:
> Are there any parisc-linux issues I need to be aware of...
I forgot to mention: HPUX and Linux must have seperate boot disks.
And read the boot/install HOW-TO that's referenced on esiee's website.
(as usual, www.parisc-linux.org has the links on the front page)
grant
^ permalink raw reply
* Re: [parisc-linux] rp2430 questions
From: Grant Grundler @ 2002-12-19 1:26 UTC (permalink / raw)
To: Gavin Hubbard; +Cc: parisc-linux
In-Reply-To: <20021219005118.LJTP14518.web4-rme.xtra.co.nz@[127.0.0.1]>
On Thu, Dec 19, 2002 at 01:51:18PM +1300, Gavin Hubbard wrote:
> 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?
Nope. You will want to upgrade the kernel ASAP though.
Get the latest 2.4.19 kernel you can find.
> 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?
We don't have any rp2430's here to test such an upgrade.
But I can't imagine any difference besides the additional (faster?) CPU
(and more memory) getting recogized. Should your root disk get renamed,
it's possible to recovery from that pretty easily - I've done it
more than a few times.
grant
^ permalink raw reply
* Re: [PATCH][2.4] generic cluster APIC support for systems with more than 8 CPUs
From: James Cleverdon @ 2002-12-19 1:32 UTC (permalink / raw)
To: Pallipadi, Venkatesh, Linux Kernel, Christoph Hellwig
Cc: Martin Bligh, John Stultz, Nakajima, Jun, Mallick, Asit K,
Saxena, Sunil
In-Reply-To: <C8C38546F90ABF408A5961FC01FDBF1912E190@fmsmsx405.fm.intel.com>
On Wednesday 18 December 2002 05:05 pm, Pallipadi, Venkatesh wrote:
> 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?
Sure, I can verify it. The I/O APICs in shipped summit chipsets contains a
version ID of 0x11 instead of 0x14 to 0x1F. The high performance folks
claimed that Intel specified 0x14 for the local APICs, but left their orange
jacket docs saying 0x1X for I/O APICs until after the chips taped out.
Whatever. In any case, there are boxes in the field that contain those
version numbers. We can recognize them using the OEM and product strings in
the MPS and ACPI tables, so it's only an annoyance.
> > 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
--
James Cleverdon
IBM xSeries Linux Solutions
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com
^ permalink raw reply
* Re: 15000+ processes -- poor performance ?!
From: David Lang @ 2002-12-19 1:20 UTC (permalink / raw)
To: William Lee Irwin III
Cc: Till Immanuel Patzschke, lse-tech, linux-kernel@vger.kernel.org
In-Reply-To: <20021219012549.GK31800@holomorphy.com>
Ok, I wasn't sure of the cause, but I've seen this as far back as 2.2 I
had a machine trying to run 2000 processes under 2.2 and 2.4.0 (after
upping the 2.2 kernel limit) and top would cost me ~40% throughput on the
machine (while claiming it was useing ~5% of the CPU)
David Lang
On Wed, 18 Dec 2002, William Lee Irwin III wrote:
> Date: Wed, 18 Dec 2002 17:25:49 -0800
> From: William Lee Irwin III <wli@holomorphy.com>
> To: David Lang <dlang@diginsite.com>
> Cc: Till Immanuel Patzschke <tip@inw.de>,
> lse-tech <lse-tech@lists.sourceforge.net>,
> "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
> Subject: Re: 15000+ processes -- poor performance ?!
>
> On Wed, Dec 18, 2002 at 05:12:41PM -0800, David Lang wrote:
> > also top is very inefficant with large numbers of processes. use vmstat
> > or cat out the files in /proc to get the info more efficiantly (it won't
> > get you per process info, but it son't cause the interferance with your
> > desired load that top gives you.)
>
> It's mostly just the fact top(1) doesn't scan /proc/ incrementally and
> that proc_pid_readdir() is quadratic in the number of tasks.
>
>
> Bill
>
^ permalink raw reply
* [BENCHMARK] scheduler tunables with contest - max_timeslice
From: Con Kolivas @ 2002-12-19 1:31 UTC (permalink / raw)
To: linux kernel mailing list; +Cc: Robert Love, Ingo Molnar
Using the osdl (http://www.osdl.org) resources provided to me I'm running a
series of contest benchmarks on 2.5.52-mm1 and modifying the scheduler tunables
as provided by RML's patch. SMP used to minimise how long it will take me to do
these. This is the first in the series and I've run a range of max_timeslices
(default is 300ms; range 100-400):
noload:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.52-mm1 [8] 39.7 180 0 0 1.10
max_tim100 [3] 39.7 180 0 0 1.10
max_tim200 [3] 39.6 180 0 0 1.09
max_tim400 [3] 39.7 181 0 0 1.10
cacherun:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.52-mm1 [7] 36.9 194 0 0 1.02
max_tim100 [3] 36.7 194 0 0 1.01
max_tim200 [3] 36.8 193 0 0 1.02
max_tim400 [3] 36.8 194 0 0 1.02
process_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.52-mm1 [7] 49.0 144 10 50 1.35
max_tim100 [3] 52.5 133 14 60 1.45
max_tim200 [3] 47.8 150 9 43 1.32
max_tim400 [3] 48.3 146 10 48 1.33
Slight balance change here. Note process load forks off 4*num_cpus processes
that do their task in a very short time and shortening the max timeslice seems
to slightly favour these tasks at the expense of kernel compilation time.
ctar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.52-mm1 [7] 55.5 156 1 10 1.53
max_tim100 [3] 56.0 156 1 10 1.55
max_tim200 [3] 53.9 162 1 10 1.49
max_tim400 [3] 55.5 148 1 10 1.53
xtar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.52-mm1 [7] 77.4 122 1 8 2.14
max_tim100 [3] 73.0 123 1 8 2.02
max_tim200 [3] 82.5 115 1 8 2.28
max_tim400 [3] 82.8 117 1 9 2.29
io_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.52-mm1 [7] 80.5 108 10 19 2.22
max_tim100 [3] 93.8 100 13 20 2.59
max_tim200 [3] 88.8 98 12 19 2.45
max_tim400 [3] 71.4 114 8 18 1.97
The trend here is one of definite shortening of duration of kernel compilation
during io load as the max timeslice is made longer
io_other:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.52-mm1 [7] 60.1 131 7 18 1.66
max_tim100 [3] 64.5 127 8 19 1.78
max_tim200 [3] 62.8 125 8 19 1.73
max_tim400 [3] 62.5 126 6 15 1.73
read_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.52-mm1 [7] 49.9 149 5 6 1.38
max_tim100 [3] 50.4 150 5 6 1.39
max_tim200 [3] 50.5 149 5 6 1.39
max_tim400 [3] 50.6 148 5 6 1.40
list_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.52-mm1 [7] 43.8 167 0 9 1.21
max_tim100 [3] 44.2 166 0 9 1.22
max_tim200 [3] 43.6 168 0 9 1.20
max_tim400 [3] 43.3 167 0 9 1.20
mem_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.52-mm1 [7] 71.1 123 36 2 1.96
max_tim100 [3] 81.1 100 38 2 2.24
max_tim200 [3] 84.1 101 36 2 2.32
max_tim400 [3] 82.8 97 36 2 2.29
No idea what's going on in mem_load
I will continue to do these with some of the other scheduler tunables. I will
need recommendations if anyone is interested in further resolution testing than
that I'm currently doing.
Con
^ permalink raw reply
* Re: 15000+ processes -- poor performance ?!
From: William Lee Irwin III @ 2002-12-19 1:25 UTC (permalink / raw)
To: David Lang
Cc: Till Immanuel Patzschke, lse-tech, linux-kernel@vger.kernel.org
In-Reply-To: <Pine.LNX.4.44.0212181711200.7848-100000@dlang.diginsite.com>
On Wed, Dec 18, 2002 at 05:12:41PM -0800, David Lang wrote:
> also top is very inefficant with large numbers of processes. use vmstat
> or cat out the files in /proc to get the info more efficiantly (it won't
> get you per process info, but it son't cause the interferance with your
> desired load that top gives you.)
It's mostly just the fact top(1) doesn't scan /proc/ incrementally and
that proc_pid_readdir() is quadratic in the number of tasks.
Bill
^ permalink raw reply
* Re: [Lse-tech] Re: 15000+ processes -- poor performance ?!
From: William Lee Irwin III @ 2002-12-19 1:24 UTC (permalink / raw)
To: Till Immanuel Patzschke, lse-tech, linux-kernel@vger.kernel.org
In-Reply-To: <20021219011541.GI31800@holomorphy.com>
On Wed, Dec 18, 2002 at 04:53:45PM -0800, Till Immanuel Patzschke wrote:
>> forgot the kernel version (2.4.20aa1)...
On Wed, Dec 18, 2002 at 05:15:41PM -0800, William Lee Irwin III wrote:
> 2.4.20aa1 is missing some of the infrastructure to reduce the cpu
> consumption under high process count loads, but that's not going to
> help you anyway. 150K processes is not going to be feasible in the
> immediate future (months or longer away) so you'll have to figure out
> how to take that into account.
Er, sorry, on a brief rereading my eyes deceived me and I thought an
extra zero got in there. 15K is fine on 2.5 + patches.
Bill
^ permalink raw reply
* Re: 15000+ processes -- poor performance ?!
From: David Lang @ 2002-12-19 1:12 UTC (permalink / raw)
To: William Lee Irwin III
Cc: Till Immanuel Patzschke, lse-tech, linux-kernel@vger.kernel.org
In-Reply-To: <20021219011541.GI31800@holomorphy.com>
also top is very inefficant with large numbers of processes. use vmstat
or cat out the files in /proc to get the info more efficiantly (it won't
get you per process info, but it son't cause the interferance with your
desired load that top gives you.)
David Lang
On Wed, 18 Dec 2002, William Lee Irwin
III wrote:
> Date: Wed, 18 Dec 2002 17:15:41 -0800
> From: William Lee Irwin III <wli@holomorphy.com>
> To: Till Immanuel Patzschke <tip@inw.de>
> Cc: lse-tech <lse-tech@lists.sourceforge.net>,
> "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
> Subject: Re: 15000+ processes -- poor performance ?!
>
> On Wed, Dec 18, 2002 at 04:53:45PM -0800, Till Immanuel Patzschke wrote:
> > forgot the kernel version (2.4.20aa1)...
>
> 2.4.20aa1 is missing some of the infrastructure to reduce the cpu
> consumption under high process count loads, but that's not going to
> help you anyway. 150K processes is not going to be feasible in the
> immediate future (months or longer away) so you'll have to figure out
> how to take that into account.
>
>
> Bill
> -
> 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 : Linux 2.4.21-pre2 - unresolved
From: Jean Tourrilhes @ 2002-12-19 1:21 UTC (permalink / raw)
To: Linux kernel mailing list, Eyal Lebedinsky; +Cc: Marcelo Tosatti
Eyal Lebedinsky wrote :
>
> depmod: *** Unresolved symbols in
> /lib/modules/2.4.21-pre2/kernel/net/irda/irda.o
> depmod: irlmp_lap_tx_queue_full
It looks like Marcelo did drop some of my IrDA patches (the
LAP scheduler to be exact). You can find the necessary patch on my web
page.
I'll compile 21-pre2 and I'll deal with that with Marcelo.
Have fun...
Jean
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Linus Torvalds @ 2002-12-19 1:17 UTC (permalink / raw)
To: Alan Cox
Cc: John Bradford, Larry McVoy, lm, alan, davej, vonbrand,
Linux Kernel Mailing List, akpm
In-Reply-To: <1040260157.26882.7.camel@irongate.swansea.linux.org.uk>
On 19 Dec 2002, Alan Cox wrote:
>
> How the actual patches get applied really isnt relevant. I know Linus
> hated jitterbug, Im guessing he hates bugzilla too ?
I didn't start out hating jitterbug, I tried it for a while.
I ended up not really being able to work with anything that was so
email-hostile. You had to click on things from a browser, write passwords,
and generally just act "gooey", instead of getting things just _done_.
If I can't do my work by email from a standard keyboard interface, it's
just not worth it. Maybe bugzilla works better, but I seriously expect it
to help _others_ track bugs more than it helps me.
Which is fine. We don't all have to agree on the tools or on how to track
stuff. The worst we can do (I think) is to _force_ people to work some
way.
[ This is where the angel chorus behind me started singing "Why can't we
all live together in peace and harmony" and put up a big banner saying
"Larry [heart] Alan". At that point my fever-induced brain just said
"plop" ]
Linus
^ permalink raw reply
* Re: After Uncompresseing Linux..., what's next
From: Jim Potter @ 2002-12-19 1:09 UTC (permalink / raw)
To: Prakash kanthi; +Cc: LinuxPPC
In-Reply-To: <20021219001423.47019.qmail@web41207.mail.yahoo.com>
What hardware are you booting?
What bootloader are you using (PPCboot, DINK, etc)?
Do you have a BDI2000 -- you could look at the target memory to see what's
happening. Alternatively, you could throw in some print statements dumping
the target memory before jumping to it. Also some print statements to show
what's happening when you're uncompressing the kernel might be helpful.
You might want to have a look at your caches, making sure they're flushed
(etc).
> Hi there,
>
> I was trying to load linuxppc_2_4_devel onto my board.
> It goes through the board info read, UART init and
> Uncompressing the linux kernel. But after that, i do
> not see any messages and board hangs.
>
> Here is the UART output:
> ------------------------------------
> OS Booting...
>
> loaded at: 00400000 0060D1CC
> board data at: 00000030 00000044
> relocated to: 00405C24 00405C38
> zimage at: 00406290 004A08FF
> initrd at: 004A1000 006097CA
> avail ram: 0060E000 007F8000
>
> Linux/PPC load: console=ttyS0,9600 console=tty1 ip=on
> root=/dev/xsysace/disc0/pa
> rt3 rw
> Uncompressing Linux...done.
> Now booting the kernel
> -------------------------------------------
>
> After the last line, it hangs. I get a feeling that,
> the uncompressing process is not writing in the memory
> starting from 0x00000000 and, after uncompressing, it
> is jumping into 0x00000000 and is not able to find
> anything.
>
> My questions are,
> 1. How can i make sure that, the uncompressing process
> is going to start writing the data from 0x00000000.
>
> 2. How big a space this uncompressing process needs?
> And also how much overall memory is required for
> running linux. I just have 8MB SDRAM.
>
> 3. What is the next step in the booting process? Which
> Device (eth, pci, ide, ???) Initialization?
>
> Your help is appreciated.
>
> thanks,
> Prakash
>
--
Sincerely,
Jim Potter
45th Parallel Processing
Firefighting: Bustin' ours, Savin' yours.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: 15000+ processes -- poor performance ?!
From: William Lee Irwin III @ 2002-12-19 1:15 UTC (permalink / raw)
To: Till Immanuel Patzschke; +Cc: lse-tech, linux-kernel@vger.kernel.org
In-Reply-To: <3E011899.A3FBDAF1@inw.de>
On Wed, Dec 18, 2002 at 04:53:45PM -0800, Till Immanuel Patzschke wrote:
> forgot the kernel version (2.4.20aa1)...
2.4.20aa1 is missing some of the infrastructure to reduce the cpu
consumption under high process count loads, but that's not going to
help you anyway. 150K processes is not going to be feasible in the
immediate future (months or longer away) so you'll have to figure out
how to take that into account.
Bill
^ permalink raw reply
* Re: how to delete a piece of rule in iptables?
From: Jason Huang @ 2002-12-19 1:09 UTC (permalink / raw)
To: bobo; +Cc: netfilter-devel@lists.netfilter.org, bobowd@sohu.com
In-Reply-To: <200212181230.UAA02960@email.whu.edu.cn>
bobo 提到:
> i have insert some rules to iptables firewall.now,i would
>like to delete it .
>but i only know to use iptalbes -L to empty them.
>but it lead to delete all the rules in it.
>how to do ??
>
>
>
>
>
This address is for developer, your question should be post in user
mailinglist.
The "-L" option will list all rules, use belows to flush it and use "man
iptables" to see more.
iptables -F
iptables -F -t nat
iptables -F -t mangle
iptables -X
iptables -X nat
iptables -X mangle
/Jason
^ permalink raw reply
* RE: 3ware driver in 2.4.x and 2.5.x not compatible with 6x00 seri es cards
From: Bryan O'Sullivan @ 2002-12-19 1:14 UTC (permalink / raw)
To: Adam Radford
Cc: 'Dave Jones', Nathan Neulinger, linux-kernel, uetrecht
In-Reply-To: <A1964EDB64C8094DA12D2271C04B812672C927@tabby>
On Wed, 2002-12-18 at 10:41, Adam Radford wrote:
> If it isn't working for you, let me know.
Remember the crusty firmware problems I reported? :-)
I've already sent out a patch in another offshoot of this thread.
<b
^ permalink raw reply
* modules oops in 2.5.52
From: Jeremy Fitzhardinge @ 2002-12-19 1:14 UTC (permalink / raw)
To: Rusty Russell; +Cc: Linux Kernel List
Hi,
I just had an oops in the modules code:
Dec 18 16:58:59 ixodes kernel: Unable to handle kernel paging request at virtual address f8980924
Dec 18 16:58:59 ixodes kernel: printing eip:
Dec 18 16:58:59 ixodes kernel: f896756d
Dec 18 16:58:59 ixodes kernel: *pde = 01bfc067
Dec 18 16:58:59 ixodes kernel: *pte = 00000000
Dec 18 16:58:59 ixodes kernel: Oops: 0000
Dec 18 16:58:59 ixodes kernel: CPU: 0
Dec 18 16:58:59 ixodes kernel: EIP: 0060:[<f896756d>] Not tainted
Dec 18 16:58:59 ixodes kernel: EFLAGS: 00010282
Dec 18 16:58:59 ixodes kernel: EIP is at __exitfn+0xd/0x4c [parport_pc]
Dec 18 16:58:59 ixodes kernel: eax: d7b01c80 ebx: c0355bb8 ecx: c0355bb8 edx: c02f2b50
Dec 18 16:58:59 ixodes kernel: esi: f8964000 edi: 00000000 ebp: f4b9df5c esp: f4b9df50
Dec 18 16:58:59 ixodes kernel: ds: 0068 es: 0068 ss: 0068
Dec 18 16:58:59 ixodes kernel: Process modprobe (pid: 1358, threadinfo=f4b9c000 task=eb929280)
Dec 18 16:58:59 ixodes kernel: Stack: f4b9c000 c0355bb8 f8964000 f4b9dfbc c0127d61 c02f2b50 00000077 0000003b
Dec 18 16:58:59 ixodes kernel: 70726170 5f74726f e1006370 f5025480 f5025380 40013000 40014000 f5025480
Dec 18 16:58:59 ixodes kernel: f5025380 e1e4b200 e1e4b220 00000000 f4b9dfbc c0136839 00e4b200 40013000
Dec 18 16:58:59 ixodes kernel: Call Trace:
Dec 18 16:58:59 ixodes kernel: [<c0127d61>] sys_delete_module+0x1bf/0x1e2
Dec 18 16:58:59 ixodes kernel: [<c0136839>] sys_munmap+0x57/0x76
Dec 18 16:58:59 ixodes kernel: [<c01090c3>] syscall_call+0x7/0xb
Dec 18 16:58:59 ixodes kernel:
Dec 18 16:58:59 ixodes kernel: Code: 8b 35 24 09 98 f8 85 f6 89 c3 74 24 85 db 74 0f f6 43 10 01
Dec 18 16:59:00 ixodes kernel: end_request: I/O error, dev hdc, sector 0
Dec 18 16:59:00 ixodes kernel: end_request: I/O error, dev hdc, sector 0
I doubt parport_pc was being used. I think this was caused by the
vmware-config script trying to unload modules. Vmware was not loaded at
the time.
Now, any process which touches /proc/modules hangs, I guess because a
lock was being held.
I have module-init-tools 0.9.3 installed.
The only other patch in the kernel is AndrewM's buffer head tracing
code.
J
^ permalink raw reply
* Re: 15000+ processes -- poor performance ?!
From: William Lee Irwin III @ 2002-12-19 1:11 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:
> 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...).
You're for the most part SOL unless you can either hack the support or
can wait for it to be finished. More details below.
On Wed, Dec 18, 2002 at 04:46:15PM -0800, Till Immanuel Patzschke wrote:
> 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!
Try 2.5.52-mm1 + 2.5.52-wli-1. The -wli bits are orthogonal but they do
a small bit to reduce the cpu inefficiencies of many task loads.
-wli is actually maintenance and follow-through on various early 2.5
promises.
proc_pid_readdir() is the cpu culprit, which I have not yet addressed.
You are also going to have severe memory management problems due to the
number of L2 and L3 pagetables created as well as kernel stacks.
2.5.52-mm1 will have 2 of 3 possible things that can be done about L3
pagetables. L2 pagetables limit you to 64K processes with more practical
limits around 16K. As 16K is feasible here, you are running the wrong
kernel version(s).
Bill
^ permalink raw reply
* RE: 15000+ processes -- poor performance ?!
From: Robert Love @ 2002-12-19 1:13 UTC (permalink / raw)
To: Perez-Gonzalez, Inaky
Cc: 'Till Immanuel Patzschke', lse-tech, linux-kernel
In-Reply-To: <A46BBDB345A7D5118EC90002A5072C7806CACA2C@orsmsx116.jf.intel.com>
On Wed, 2002-12-18 at 20:04, Perez-Gonzalez, Inaky wrote:
> >
> > 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.
2.4-aa has the O(1) scheduler, yes.
I think 15,000 processes may always suck, though :)
Robert Love
^ permalink raw reply
* Re: 3ware driver in 2.4.x and 2.5.x not compatible with 6x00 series cards
From: Bryan O'Sullivan @ 2002-12-19 1:11 UTC (permalink / raw)
To: Alan Cox; +Cc: Nathan Neulinger, Linux Kernel Mailing List, uetrecht
In-Reply-To: <1040242085.24561.22.camel@irongate.swansea.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 601 bytes --]
On Wed, 2002-12-18 at 12:08, Alan Cox wrote:
> Please give the name of your 3ware contact so someone competent in 3ware
> so they can be 're-educated'
>
> I use the new driver with an old card, it works.
I've talked with some clue-enabled people at 3ware about this. The
newest driver is indeed broken on cards with very old firmware, and the
next revision of the driver will fix that problem.
There's a trivial fix for 2.4.20: just get rid of the error case around
line 1016 of 3w-xxxx.c. This is basically the fix 3ware is planning to
include in the next driver release.
Patch attached.
<b
[-- Attachment #2: 3ware.patch --]
[-- Type: text/x-patch, Size: 610 bytes --]
diff -u /home/bos/3w-xxxx.c.~1~ /home/bos/3w-xxxx.c
--- /home/bos/3w-xxxx.c.~1~ 2002-12-18 17:09:20.000000000 -0800
+++ /home/bos/3w-xxxx.c 2002-12-18 17:09:20.000000000 -0800
@@ -1014,12 +1014,6 @@
error = tw_setfeature(tw_dev2, 2, 1, &c);
if (error) {
printk(KERN_WARNING "3w-xxxx: tw_setfeature(): Error setting features for card %d.\n", j);
- scsi_unregister(host);
- release_region((tw_dev->tw_pci_dev->resource[0].start), TW_IO_ADDRESS_RANGE);
- tw_free_device_extension(tw_dev);
- kfree(tw_dev);
- numcards--;
- continue;
}
/* Now setup the interrupt handler */
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Adam J. Richter @ 2002-12-19 1:08 UTC (permalink / raw)
To: rmk; +Cc: linux-kernel
Russell King wrote:
>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.
I don't currently use bugzilla (just due to inertia), but the
whole world doesn't have to switch to something overnight in order for
that facility to end up saving more time and resources than it has
cost. Adoption can grow gradually, and it's probably easier to work
out bugs (in bugzilla) and improvements that way anyhow.
Adam J. Richter __ ______________ 575 Oroville Road
adam@yggdrasil.com \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
^ 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.