* Re: 2.5.69-mm8
2003-05-22 9:16 2.5.69-mm8 Andrew Morton
@ 2003-05-22 12:05 ` Philippe Gramoullé
2003-05-22 12:07 ` 2.5.69-mm8 Helge Hafting
` (5 subsequent siblings)
6 siblings, 0 replies; 19+ messages in thread
From: Philippe Gramoullé @ 2003-05-22 12:05 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, linux-mm
Hello Andrew,
It works fine here on a Dell Inspiron 8000 using elevator=as
I have a minor warning for the i8k module though:
WARNING: /lib/modules/2.5.69-mm8/kernel/drivers/char/i8k.ko needs unknown symbol SET_MODULE_OWNER
Thanks,
Philippe
--
Philippe Gramoullé
philippe.gramoulle@mmania.com
Lycos Europe - NOC France
On Thu, 22 May 2003 02:16:52 -0700
Andrew Morton <akpm@digeo.com> wrote:
|
| ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.69-mm8/
|
| . One anticipatory scheduler patch, but it's a big one. I have not stress
| tested it a lot. If it explodes please report it and then boot with
| elevator=deadline.
|
| . The slab magazine layer code is in its hopefully-final state.
|
| . Some VFS locking scalability work - stress testing of this would be
| useful.
|
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: 2.5.69-mm8
2003-05-22 9:16 2.5.69-mm8 Andrew Morton
2003-05-22 12:05 ` 2.5.69-mm8 Philippe Gramoullé
@ 2003-05-22 12:07 ` Helge Hafting
2003-05-22 21:21 ` 2.5.69-mm8 Rudmer van Dijk
2003-05-22 14:55 ` 2.5.69-mm8 William Lee Irwin III
` (4 subsequent siblings)
6 siblings, 1 reply; 19+ messages in thread
From: Helge Hafting @ 2003-05-22 12:07 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.69-mm8/
>
> . One anticipatory scheduler patch, but it's a big one. I have not stress
> tested it a lot. If it explodes please report it and then boot with
> elevator=deadline.
>
> . The slab magazine layer code is in its hopefully-final state.
>
> . Some VFS locking scalability work - stress testing of this would be
> useful.
It seems to work fine for UP and survives a kernel compile.
Helge Hafting
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: 2.5.69-mm8
2003-05-22 12:07 ` 2.5.69-mm8 Helge Hafting
@ 2003-05-22 21:21 ` Rudmer van Dijk
0 siblings, 0 replies; 19+ messages in thread
From: Rudmer van Dijk @ 2003-05-22 21:21 UTC (permalink / raw)
To: Helge Hafting, Andrew Morton; +Cc: linux-kernel, linux-mm
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 22 May 2003 14:07, Helge Hafting wrote:
> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.
> >69-mm8/
> >
> > . One anticipatory scheduler patch, but it's a big one. I have not
> > stress tested it a lot. If it explodes please report it and then boot
> > with elevator=deadline.
> >
> > . The slab magazine layer code is in its hopefully-final state.
> >
> > . Some VFS locking scalability work - stress testing of this would be
> > useful.
>
> It seems to work fine for UP and survives a kernel compile.
also for me, UP no preempt and it is running for 11 hours now without
problems. It survived a kernel compile, compilation of the kde-network
package and every other normal desktop-system usage.
Rudmer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE+zT9ShvANkaSdp/IRAh/IAJ4wuUoONk96noYpbLJOBbhvDsmNwwCeKsNa
S9VGQ6HCiwrlQJv2rEjOBMA=
=386g
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 2.5.69-mm8
2003-05-22 9:16 2.5.69-mm8 Andrew Morton
2003-05-22 12:05 ` 2.5.69-mm8 Philippe Gramoullé
2003-05-22 12:07 ` 2.5.69-mm8 Helge Hafting
@ 2003-05-22 14:55 ` William Lee Irwin III
2003-05-22 17:13 ` 2.5.69-mm8 Alexander Hoogerhuis
` (3 subsequent siblings)
6 siblings, 0 replies; 19+ messages in thread
From: William Lee Irwin III @ 2003-05-22 14:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
On Thu, May 22, 2003 at 02:16:52AM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.69-mm8/
> . One anticipatory scheduler patch, but it's a big one. I have not stress
> tested it a lot. If it explodes please report it and then boot with
> elevator=deadline.
> . The slab magazine layer code is in its hopefully-final state.
> . Some VFS locking scalability work - stress testing of this would be
> useful.
Looks like this bit fell out from mainline; required for CONFIG_NUMA
to compile and identical to mainline.
-- wli
diff -prauN mm8-2.5.69-1/kernel/sched.c mm8-2.5.69-2/kernel/sched.c
--- mm8-2.5.69-1/kernel/sched.c 2003-05-22 04:54:59.000000000 -0700
+++ mm8-2.5.69-2/kernel/sched.c 2003-05-22 07:35:01.000000000 -0700
@@ -1084,6 +1084,9 @@ static void balance_node(runqueue_t *thi
static void rebalance_tick(runqueue_t *this_rq, int idle)
{
+#ifdef CONFIG_NUMA
+ int this_cpu = smp_processor_id();
+#endif
unsigned long j = jiffies;
/*
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: 2.5.69-mm8
2003-05-22 9:16 2.5.69-mm8 Andrew Morton
` (2 preceding siblings ...)
2003-05-22 14:55 ` 2.5.69-mm8 William Lee Irwin III
@ 2003-05-22 17:13 ` Alexander Hoogerhuis
2003-05-22 18:53 ` 2.5.69-mm8 Felipe Alfaro Solana
` (2 subsequent siblings)
6 siblings, 0 replies; 19+ messages in thread
From: Alexander Hoogerhuis @ 2003-05-22 17:13 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andrew Morton <akpm@digeo.com> writes:
>
> [SNIP]
>
Still some guff in the log on shutdown regarding the USB hub, but now
it doesn't do instant improvisations of a doorstop :) Other than that,
it's still alive after a few hours of banging on it, even toying with
vmware 4.0 :)
mvh,
A
- --
Alexander Hoogerhuis | alexh@ihatent.com
CCNP - CCDP - MCNE - CCSE | +47 908 21 485
"You have zero privacy anyway. Get over it." --Scott McNealy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQE+zQUrCQ1pa+gRoggRAjePAJ96nazhfgP2ZZXOH4rZFYfrI4IitACdHsWG
xPJbUVuXJQ/r2iJA//q8/UI=
=5hye
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: 2.5.69-mm8
2003-05-22 9:16 2.5.69-mm8 Andrew Morton
` (3 preceding siblings ...)
2003-05-22 17:13 ` 2.5.69-mm8 Alexander Hoogerhuis
@ 2003-05-22 18:53 ` Felipe Alfaro Solana
2003-05-22 19:30 ` 2.5.69-mm8 Paul Larson
2003-05-23 6:18 ` 2.5.69-mm8 Martin J. Bligh
2003-05-23 17:23 ` 2.5.69-mm8 Arador
6 siblings, 1 reply; 19+ messages in thread
From: Felipe Alfaro Solana @ 2003-05-22 18:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: LKML, linux-mm
On Thu, 2003-05-22 at 11:16, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.69-mm8/
>
> . One anticipatory scheduler patch, but it's a big one. I have not stress
> tested it a lot. If it explodes please report it and then boot with
> elevator=deadline.
>
> . The slab magazine layer code is in its hopefully-final state.
>
> . Some VFS locking scalability work - stress testing of this would be
> useful.
Running on it right now... Compiles and boots. I'm sure it won't explode
on my face :-)
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: 2.5.69-mm8
2003-05-22 18:53 ` 2.5.69-mm8 Felipe Alfaro Solana
@ 2003-05-22 19:30 ` Paul Larson
2003-05-22 19:39 ` 2.5.69-mm8 Martin J. Bligh
2003-05-22 20:14 ` 2.5.69-mm8 Andrew Morton
0 siblings, 2 replies; 19+ messages in thread
From: Paul Larson @ 2003-05-22 19:30 UTC (permalink / raw)
To: Felipe Alfaro Solana; +Cc: Andrew Morton, lkml, linux-mm
[-- Attachment #1: Type: text/plain, Size: 967 bytes --]
On Thu, 2003-05-22 at 13:53, Felipe Alfaro Solana wrote:
> On Thu, 2003-05-22 at 11:16, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.69-mm8/
> >
> > . One anticipatory scheduler patch, but it's a big one. I have not stress
> > tested it a lot. If it explodes please report it and then boot with
> > elevator=deadline.
> >
> > . The slab magazine layer code is in its hopefully-final state.
> >
> > . Some VFS locking scalability work - stress testing of this would be
> > useful.
>
> Running on it right now... Compiles and boots. I'm sure it won't explode
> on my face :-)
2.5.69-mm8 is bleeding for me. :) See bugs #738 and #739. I don't
*think* they are the same but apologies in advance if they are. #738
appears to have been produced mostly by running LTP and #739 I got with
a combination of ftest07 and aio01 from LTP and previously just by
compiling LTP.
-Paul Larson
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 240 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 2.5.69-mm8
2003-05-22 19:30 ` 2.5.69-mm8 Paul Larson
@ 2003-05-22 19:39 ` Martin J. Bligh
2003-05-22 19:49 ` 2.5.69-mm8 Paul Larson
2003-05-22 21:03 ` 2.5.69-mm8 Dave Hansen
2003-05-22 20:14 ` 2.5.69-mm8 Andrew Morton
1 sibling, 2 replies; 19+ messages in thread
From: Martin J. Bligh @ 2003-05-22 19:39 UTC (permalink / raw)
To: Paul Larson, Felipe Alfaro Solana; +Cc: Andrew Morton, lkml, linux-mm
>> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.69-mm8/
>> >
>> > . One anticipatory scheduler patch, but it's a big one. I have not stress
>> > tested it a lot. If it explodes please report it and then boot with
>> > elevator=deadline.
>> >
>> > . The slab magazine layer code is in its hopefully-final state.
>> >
>> > . Some VFS locking scalability work - stress testing of this would be
>> > useful.
>>
>> Running on it right now... Compiles and boots. I'm sure it won't explode
>> on my face :-)
> 2.5.69-mm8 is bleeding for me. :) See bugs #738 and #739. I don't
> *think* they are the same but apologies in advance if they are. #738
> appears to have been produced mostly by running LTP and #739 I got with
> a combination of ftest07 and aio01 from LTP and previously just by
> compiling LTP.
Also seems to hang rather easily. When it gets into that state, it's difficult
to tell what works and what doesn't ... I can login over serial, but not
start new ssh's and "ps -ef" hangs for ever. I'll try to get some more
information, and assemble a less-totally-crap bug report.
M.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 2.5.69-mm8
2003-05-22 19:39 ` 2.5.69-mm8 Martin J. Bligh
@ 2003-05-22 19:49 ` Paul Larson
2003-05-22 21:03 ` 2.5.69-mm8 Dave Hansen
1 sibling, 0 replies; 19+ messages in thread
From: Paul Larson @ 2003-05-22 19:49 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Felipe Alfaro Solana, Andrew Morton, lkml, linux-mm
[-- Attachment #1: Type: text/plain, Size: 411 bytes --]
On Thu, 2003-05-22 at 14:39, Martin J. Bligh wrote:
> Also seems to hang rather easily. When it gets into that state, it's difficult
> to tell what works and what doesn't ... I can login over serial, but not
> start new ssh's and "ps -ef" hangs for ever. I'll try to get some more
> information, and assemble a less-totally-crap bug report.
ssh and ps -ef seem to work fine on my machine
-Paul Larson
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 240 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 2.5.69-mm8
2003-05-22 19:39 ` 2.5.69-mm8 Martin J. Bligh
2003-05-22 19:49 ` 2.5.69-mm8 Paul Larson
@ 2003-05-22 21:03 ` Dave Hansen
1 sibling, 0 replies; 19+ messages in thread
From: Dave Hansen @ 2003-05-22 21:03 UTC (permalink / raw)
To: Martin J. Bligh
Cc: Paul Larson, Felipe Alfaro Solana, Andrew Morton, lkml, linux-mm
On Thu, 2003-05-22 at 12:39, Martin J. Bligh wrote:
> Also seems to hang rather easily. When it gets into that state, it's difficult
> to tell what works and what doesn't ... I can login over serial, but not
> start new ssh's and "ps -ef" hangs for ever. I'll try to get some more
> information, and assemble a less-totally-crap bug report.
Give sysrq 't' a shot
echo t > /proc/sysrq-trigger
--
Dave Hansen
haveblue@us.ibm.com
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 2.5.69-mm8
2003-05-22 19:30 ` 2.5.69-mm8 Paul Larson
2003-05-22 19:39 ` 2.5.69-mm8 Martin J. Bligh
@ 2003-05-22 20:14 ` Andrew Morton
2003-05-22 21:19 ` 2.5.69-mm8 Paul Larson
1 sibling, 1 reply; 19+ messages in thread
From: Andrew Morton @ 2003-05-22 20:14 UTC (permalink / raw)
To: Paul Larson; +Cc: felipe_alfaro, linux-kernel, linux-mm
Paul Larson <plars@linuxtestproject.org> wrote:
>
> 2.5.69-mm8 is bleeding for me. :) See bugs #738 and #739.
#739 seems to be the b_committed_data race. Alex is cooking up a fix for
that. Sorry, I didn't realise it was that easy to trigger.
I'm fairly amazed about #738. The asertion at fs/jbd/transaction.c:2023
(J_ASSERT_JH(jh, kernel_locked())) is bogus and should be removed.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 2.5.69-mm8
2003-05-22 20:14 ` 2.5.69-mm8 Andrew Morton
@ 2003-05-22 21:19 ` Paul Larson
0 siblings, 0 replies; 19+ messages in thread
From: Paul Larson @ 2003-05-22 21:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: felipe_alfaro, lkml, linux-mm
[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]
On Thu, 2003-05-22 at 15:14, Andrew Morton wrote:
> Paul Larson <plars@linuxtestproject.org> wrote:
> >
> > 2.5.69-mm8 is bleeding for me. :) See bugs #738 and #739.
>
> #739 seems to be the b_committed_data race. Alex is cooking up a fix for
> that. Sorry, I didn't realise it was that easy to trigger.
>
> I'm fairly amazed about #738. The asertion at fs/jbd/transaction.c:2023
> (J_ASSERT_JH(jh, kernel_locked())) is bogus and should be removed.
Yep, a few quick tests suggest that #739 looks to be fixed by Alex's
patch, and it removes the assert from 2023, so if that's bogus then his
patch fixes that too. I did see a hang with his patch and I wasn't able
to get any output or sysrq, so I'm going to go back and try with
nmi_watchdog to see if it'll tell me anything new. I'm not sure if I
just didn't get far enough to see this without his patch, or if it comes
in the door with it though. Also a few extra "sleeping function called
from illegal context" goodies on boot with it. I'm going to get this
test kicked of right now but I'll be out until Tuesday so if it doesn't
show up again quickly I won't be seeing it until then.
Thanks,
Paul Larson
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 240 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 2.5.69-mm8
2003-05-22 9:16 2.5.69-mm8 Andrew Morton
` (4 preceding siblings ...)
2003-05-22 18:53 ` 2.5.69-mm8 Felipe Alfaro Solana
@ 2003-05-23 6:18 ` Martin J. Bligh
2003-05-23 7:03 ` 2.5.69-mm8 Dave Hansen
2003-05-23 15:31 ` 2.5.69-mm8 Martin J. Bligh
2003-05-23 17:23 ` 2.5.69-mm8 Arador
6 siblings, 2 replies; 19+ messages in thread
From: Martin J. Bligh @ 2003-05-23 6:18 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, linux-mm
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.69-mm8/
>
> . One anticipatory scheduler patch, but it's a big one. I have not stress
> tested it a lot. If it explodes please report it and then boot with
> elevator=deadline.
>
> . The slab magazine layer code is in its hopefully-final state.
>
> . Some VFS locking scalability work - stress testing of this would be
> useful.
Well, unsure about the problems I reported earlier - seems to be related
to modem disconnects during SDET runs ... the hung session seems to lock
up the system somehow. But that could have been around for ages - I'll
try to be more scientific about reproducing it at some point.
SDET results are about the same, kernel compile is down a bit on systime
(16-way NUMA-Q)
Kernbench: (make -j vmlinux, maximal tasks)
Elapsed System User CPU
2.5.69-mm7 46.58 117.00 578.47 1492.00
2.5.69-mm8 46.09 115.11 570.74 1487.25
1004 2.0% default_idle
272 8.3% __copy_from_user_ll
129 1.7% __d_lookup
79 7.5% link_path_walk
...
-50 -1.3% find_get_page
-55 -1.5% zap_pte_range
-66 -6.5% file_move
-74 -1.2% page_add_rmap
-80 -0.6% do_anonymous_page
-110 -6.9% schedule
-139 -7.0% atomic_dec_and_lock
-698 -0.4% total
-1139 -4.6% page_remove_rmap
Not sure quite what that's all about, but there it is ;-)
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: 2.5.69-mm8
2003-05-23 6:18 ` 2.5.69-mm8 Martin J. Bligh
@ 2003-05-23 7:03 ` Dave Hansen
2003-05-23 14:32 ` 2.5.69-mm8 Martin J. Bligh
2003-05-23 15:31 ` 2.5.69-mm8 Martin J. Bligh
1 sibling, 1 reply; 19+ messages in thread
From: Dave Hansen @ 2003-05-23 7:03 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Andrew Morton, lkml, linux-mm
On Thu, 2003-05-22 at 23:18, Martin J. Bligh wrote:
> 1004 2.0% default_idle
> 272 8.3% __copy_from_user_ll
> 129 1.7% __d_lookup
> 79 7.5% link_path_walk
I have to wonder if these are cache effects, or just noise. Can you
give oprofile a try with one of the cache performance counters?
--
Dave Hansen
haveblue@us.ibm.com
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 2.5.69-mm8
2003-05-23 7:03 ` 2.5.69-mm8 Dave Hansen
@ 2003-05-23 14:32 ` Martin J. Bligh
2003-05-23 15:02 ` 2.5.69-mm8 William Lee Irwin III
0 siblings, 1 reply; 19+ messages in thread
From: Martin J. Bligh @ 2003-05-23 14:32 UTC (permalink / raw)
To: Dave Hansen; +Cc: Andrew Morton, lkml, linux-mm
>> 1004 2.0% default_idle
>> 272 8.3% __copy_from_user_ll
>> 129 1.7% __d_lookup
>> 79 7.5% link_path_walk
>
> I have to wonder if these are cache effects, or just noise. Can you
> give oprofile a try with one of the cache performance counters?
No, but you can ;-)
M.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 2.5.69-mm8
2003-05-23 14:32 ` 2.5.69-mm8 Martin J. Bligh
@ 2003-05-23 15:02 ` William Lee Irwin III
0 siblings, 0 replies; 19+ messages in thread
From: William Lee Irwin III @ 2003-05-23 15:02 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Dave Hansen, Andrew Morton, lkml, linux-mm
At some point in the past, Dave Hansen removed Martin Bligh's attribution from:
>>> 1004 2.0% default_idle
>>> 272 8.3% __copy_from_user_ll
>>> 129 1.7% __d_lookup
>>> 79 7.5% link_path_walk
At some point in the past, Martin Bligh removed Dave Hansen's attribution from:
>> I have to wonder if these are cache effects, or just noise. Can you
>> give oprofile a try with one of the cache performance counters?
On Fri, May 23, 2003 at 07:32:31AM -0700, Martin J. Bligh wrote:
> No, but you can ;-)
Cache things are usually link order and .config dependent, in 2.4.x at
least they were highly dependent on cache color conflicts between task
structures and hot codepaths and similar bizarre phenomena. i.e. exact
binutils, compiler, kernel source, and .config matches are required to
reproduce. And sometimes even that isn't enough and it's not reproducible
across runs. You also want instruction-level multiplicative differential
profiling to find cacheline bounces, not function-level additive
differential profiling, with some method of correlating assembly to source.
-- wli
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 2.5.69-mm8
2003-05-23 6:18 ` 2.5.69-mm8 Martin J. Bligh
2003-05-23 7:03 ` 2.5.69-mm8 Dave Hansen
@ 2003-05-23 15:31 ` Martin J. Bligh
1 sibling, 0 replies; 19+ messages in thread
From: Martin J. Bligh @ 2003-05-23 15:31 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, linux-mm; +Cc: haveblue
> 1004 2.0% default_idle
> 272 8.3% __copy_from_user_ll
> 129 1.7% __d_lookup
> 79 7.5% link_path_walk
> ...
> -50 -1.3% find_get_page
> -55 -1.5% zap_pte_range
> -66 -6.5% file_move
> -74 -1.2% page_add_rmap
> -80 -0.6% do_anonymous_page
> -110 -6.9% schedule
> -139 -7.0% atomic_dec_and_lock
> -698 -0.4% total
> -1139 -4.6% page_remove_rmap
>
> Not sure quite what that's all about, but there it is ;-)
WRT consistency, a second set of runs indicates it's very consistent.
And the user time is down significantly too. These are all averages
of 5 runs to start with (well, averages of the median 3 runs of 5).
Same for the profiles.
Kernbench: (make -j vmlinux, maximal tasks)
Elapsed System User CPU
2.5.69-mm7 46.58 117.00 578.47 1492.00
2.5.69-mm7-2 47.39 117.24 578.58 1468.75
2.5.69-mm8 46.09 115.11 570.74 1487.25
2.5.69-mm8-2 45.91 115.00 571.22 1494.25
The copy to/from user stuff may be noise, but page_remove_rmap and
atomic_dec_and_lock are certainly happier. Second set of runs gives:
3708 8.0% default_idle
1285 0.8% total
161 4.9% __copy_from_user_ll
95 2.5% find_get_page
77 5.8% kmem_cache_free
58 4.7% release_pages
57 5.4% link_path_walk
...
-52 -14.0% .text.lock.filemap
-62 -14.3% .text.lock.file_table
-63 -3.8% do_page_fault
-67 -3.6% path_lookup
-70 -0.5% do_anonymous_page
-84 -10.0% pte_alloc_one
-91 -5.7% schedule
-111 -11.2% clear_page_tables
-118 -6.0% atomic_dec_and_lock
-200 -3.7% __copy_to_user_ll
-338 -4.1% __d_lookup
-931 -3.8% page_remove_rmap
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: 2.5.69-mm8
2003-05-22 9:16 2.5.69-mm8 Andrew Morton
` (5 preceding siblings ...)
2003-05-23 6:18 ` 2.5.69-mm8 Martin J. Bligh
@ 2003-05-23 17:23 ` Arador
6 siblings, 0 replies; 19+ messages in thread
From: Arador @ 2003-05-23 17:23 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 10238 bytes --]
On Thu, 22 May 2003 02:16:52 -0700
Andrew Morton <akpm@digeo.com> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.69-mm8/
I still have some oopses (still compiling with gcc 3.3 btw)
It seems to happen randomly, always under X (not tested without it)
X dies after some seconds and i've to reboot (luckly the oops get
saved in the logs) using sysrq + B
May 23 18:10:48 estel kernel: Unable to handle kernel paging request at virtual address cc85c104
May 23 18:10:48 estel kernel: printing eip:
May 23 18:10:48 estel kernel: c02beaf0
May 23 18:10:48 estel kernel: *pde = 00033067
May 23 18:10:48 estel kernel: *pte = 0c85c000
May 23 18:10:48 estel kernel: Oops: 0000 [#1]
May 23 18:10:48 estel kernel: CPU: 1
May 23 18:10:48 estel kernel: EIP: 0060:[tcp_v4_rcv+528/2464] Not tainted VLI
May 23 18:10:48 estel kernel: EFLAGS: 00010286
May 23 18:10:48 estel kernel: EIP is at tcp_v4_rcv+0x210/0x9a0
May 23 18:10:48 estel kernel: eax: 00010000 ebx: cc85bf9c ecx: cfde0000 edx: cfde7490
May 23 18:10:48 estel kernel: esi: 66f71950 edi: c833d364 ebp: cff4bd88 esp: cff4bd40
May 23 18:10:48 estel kernel: ds: 007b es: 007b ss: 0068
May 23 18:10:48 estel kernel: Process events/1 (pid: 7, threadinfo=cff4a000 task=cff4ecc0)
May 23 18:10:48 estel kernel: Stack: c833d364 00000001 00000020 cf9e408c 00000000 00000000 cff4bdd8 80000000
May 23 18:10:48 estel kernel: c03bd7a8 804d3612 00000004 0000804d 587899c1 c1672264 cf9e408c c0341520
May 23 18:10:48 estel kernel: 00000000 c833d364 cff4bdac c02a0135 c833d364 c1672264 00000000 c02a0060
May 23 18:10:48 estel kernel: Call Trace:
May 23 18:10:48 estel kernel: [ip_local_deliver_finish+213/512] ip_local_deliver_finish+0xd5/0x200
May 23 18:10:48 estel kernel: [ip_local_deliver_finish+0/512] ip_local_deliver_finish+0x0/0x200
May 23 18:10:48 estel kernel: [nf_hook_slow+237/320] nf_hook_slow+0xed/0x140
May 23 18:10:48 estel kernel: [ip_local_deliver_finish+0/512] ip_local_deliver_finish+0x0/0x200
May 23 18:10:48 estel kernel: [ip_local_deliver+600/640] ip_local_deliver+0x258/0x280
May 23 18:10:48 estel kernel: [ip_local_deliver_finish+0/512] ip_local_deliver_finish+0x0/0x200
May 23 18:10:48 estel kernel: [ip_rcv+1005/1344] ip_rcv+0x3ed/0x540
May 23 18:10:48 estel kernel: [netif_receive_skb+386/528] netif_receive_skb+0x182/0x210
May 23 18:10:48 estel kernel: [process_backlog+143/304] process_backlog+0x8f/0x130
May 23 18:10:48 estel kernel: [net_rx_action+165/352] net_rx_action+0xa5/0x160
May 23 18:10:48 estel kernel: [do_softirq+216/224] do_softirq+0xd8/0xe0
May 23 18:10:48 estel kernel: [local_bh_enable+101/160] local_bh_enable+0x65/0xa0
May 23 18:10:48 estel kernel: [_end+340974994/1069786896] ppp_asynctty_receive+0x92/0x110 [ppp_async]
May 23 18:10:48 estel kernel: [flush_to_ldisc+235/384] flush_to_ldisc+0xeb/0x180
May 23 18:10:48 estel kernel: [console_callback+160/192] console_callback+0xa0/0xc0
May 23 18:10:48 estel kernel: [worker_thread+566/992] worker_thread+0x236/0x3e0
May 23 18:10:48 estel kernel: [flush_to_ldisc+0/384] flush_to_ldisc+0x0/0x180
May 23 18:10:48 estel kernel: [default_wake_function+0/48] default_wake_function+0x0/0x30
May 23 18:10:48 estel kernel: [ret_from_fork+6/20] ret_from_fork+0x6/0x14
May 23 18:10:48 estel kernel: [default_wake_function+0/48] default_wake_function+0x0/0x30
May 23 18:10:48 estel kernel: [worker_thread+0/992] worker_thread+0x0/0x3e0
May 23 18:10:48 estel kernel: [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10
May 23 18:10:48 estel kernel:
May 23 18:10:48 estel kernel: Code: 00 0f 84 74 07 00 00 8b 5b 08 85 db 75 ed a1 0c 99 36 c0 c1 e0 04 8b 5c 02 08 85 db 74 20 8d
b6 00 00 00 00 8d bc 27 00 00 00 00 <39> b3 68 01 00 00 0f 84 0a 07 00 00 8b 5b 08 85 db 75 ed f0 ff
May 23 18:10:48 estel kernel: <0>Kernel panic: Fatal exception in interrupt
May 23 18:10:48 estel kernel: In interrupt handler - not syncing
and another one; it seems to happen a few times (2, 3, 4)
in a day.
Machine is SMP P3 2x800, connected through a ppp link
with a external serial modem. gzipped .config attached.
It never happened with 2.5.69 (no bk) or before.
May 23 18:34:02 estel kernel: Unable to handle kernel paging request at virtual address ca6c403c
May 23 18:34:02 estel kernel: printing eip:
May 23 18:34:02 estel kernel: c02beaf0
May 23 18:34:02 estel kernel: *pde = 0002a067
May 23 18:34:02 estel kernel: *pte = 0a6c4000
May 23 18:34:02 estel kernel: Oops: 0000 [#1]
May 23 18:34:02 estel kernel: CPU: 0
May 23 18:34:02 estel kernel: EIP: 0060:[tcp_v4_rcv+528/2464] Not tainted VLI
May 23 18:34:02 estel kernel: EFLAGS: 00010286
May 23 18:34:02 estel kernel: EIP is at tcp_v4_rcv+0x210/0x9a0
May 23 18:34:02 estel kernel: eax: 00010000 ebx: ca6c3ed4 ecx: cfde0000 edx: cfde2000
May 23 18:34:02 estel kernel: esi: 8ec52450 edi: cfe0c084 ebp: cff4dd88 esp: cff4dd40
May 23 18:34:02 estel kernel: ds: 007b es: 007b ss: 0068
May 23 18:34:02 estel kernel: Process events/0 (pid: 6, threadinfo=cff4c000 task=cff4f2f0)
May 23 18:34:02 estel kernel: Stack: cfe0c084 00000001 00000014 cfbdd2e4 00000000 00000000 cff4ddd8 80000000
May 23 18:34:02 estel kernel: c03bd7a8 1236140e 00000004 00001236 52e563d5 cf256e68 cfbdd2e4 c0341520
May 23 18:34:02 estel kernel: 00000000 cfe0c084 cff4ddac c02a0135 cfe0c084 cf256e68 00000000 c02a0060
May 23 18:34:02 estel kernel: Call Trace:
May 23 18:34:02 estel kernel: [ip_local_deliver_finish+213/512] ip_local_deliver_finish+0xd5/0x200
May 23 18:34:02 estel kernel: [ip_local_deliver_finish+0/512] ip_local_deliver_finish+0x0/0x200
May 23 18:34:02 estel kernel: [nf_hook_slow+237/320] nf_hook_slow+0xed/0x140
May 23 18:34:02 estel kernel: [ip_local_deliver_finish+0/512] ip_local_deliver_finish+0x0/0x200
May 23 18:34:02 estel kernel: [ip_local_deliver+600/640] ip_local_deliver+0x258/0x280
May 23 18:34:02 estel kernel: [ip_local_deliver_finish+0/512] ip_local_deliver_finish+0x0/0x200
May 23 18:34:02 estel kernel: [ip_rcv+1005/1344] ip_rcv+0x3ed/0x540
May 23 18:34:02 estel kernel: [netif_receive_skb+386/528] netif_receive_skb+0x182/0x210
May 23 18:34:02 estel kernel: [process_backlog+143/304] process_backlog+0x8f/0x130
May 23 18:34:02 estel kernel: [net_rx_action+165/352] net_rx_action+0xa5/0x160
May 23 18:34:02 estel kernel: [do_softirq+216/224] do_softirq+0xd8/0xe0
May 23 18:34:02 estel kernel: [local_bh_enable+101/160] local_bh_enable+0x65/0xa0
May 23 18:34:02 estel kernel: [_end+340618642/1069786896] ppp_asynctty_receive+0x92/0x110 [ppp_async]
May 23 18:34:02 estel kernel: [flush_to_ldisc+235/384] flush_to_ldisc+0xeb/0x180
May 23 18:34:02 estel kernel: [worker_thread+566/992] worker_thread+0x236/0x3e0
May 23 18:34:02 estel kernel: [flush_to_ldisc+0/384] flush_to_ldisc+0x0/0x180
May 23 18:34:02 estel kernel: [default_wake_function+0/48] default_wake_function+0x0/0x30
May 23 18:34:02 estel kernel: [ret_from_fork+6/20] ret_from_fork+0x6/0x14
May 23 18:34:02 estel kernel: [default_wake_function+0/48] default_wake_function+0x0/0x30
May 23 18:34:02 estel kernel: [worker_thread+0/992] worker_thread+0x0/0x3e0
May 23 18:34:02 estel kernel: [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10
May 23 18:34:02 estel kernel:
May 23 18:34:02 estel kernel: Code: 00 0f 84 74 07 00 00 8b 5b 08 85 db 75 ed a1 0c 99 36 c0 c1 e0 04 8b 5c 02 08 85 db 74 20 8d
b6 00 00 00 00 8d bc 27 00 00 00 00 <39> b3 68 01 00 00 0f 84 0a 07 00 00 8b 5b 08 85 db 75 ed f0 ff
May 23 18:34:02 estel kernel: <0>Kernel panic: Fatal exception in interrupt
May 23 18:34:02 estel kernel: In interrupt handler - not syncing
May 23 18:34:18 estel kernel: Badness in local_bh_enable at kernel/softirq.c:108
May 23 18:34:18 estel kernel: Call Trace:
May 23 18:34:18 estel kernel: [local_bh_enable+144/160] local_bh_enable+0x90/0xa0
May 23 18:34:18 estel kernel: [_end+340620805/1069786896] ppp_async_push+0xf5/0x250 [ppp_async]
May 23 18:34:18 estel kernel: [_end+340618814/1069786896] ppp_asynctty_wakeup+0x2e/0x60 [ppp_async]
May 23 18:34:18 estel kernel: [uart_flush_buffer+170/240] uart_flush_buffer+0xaa/0xf0
May 23 18:34:18 estel kernel: [do_tty_hangup+1313/1472] do_tty_hangup+0x521/0x5c0
May 23 18:34:18 estel kernel: [worker_thread+566/992] worker_thread+0x236/0x3e0
May 23 18:34:18 estel kernel: [do_tty_hangup+0/1472] do_tty_hangup+0x0/0x5c0
May 23 18:34:18 estel kernel: [default_wake_function+0/48] default_wake_function+0x0/0x30
May 23 18:34:18 estel kernel: [ret_from_fork+6/20] ret_from_fork+0x6/0x14
May 23 18:34:18 estel kernel: [default_wake_function+0/48] default_wake_function+0x0/0x30
May 23 18:34:18 estel kernel: [worker_thread+0/992] worker_thread+0x0/0x3e0
May 23 18:34:18 estel kernel: [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10
May 23 18:34:18 estel kernel:
May 23 18:34:18 estel kernel: Badness in local_bh_enable at kernel/softirq.c:108
May 23 18:34:18 estel kernel: Call Trace:
May 23 18:34:18 estel kernel: [local_bh_enable+144/160] local_bh_enable+0x90/0xa0
May 23 18:34:18 estel kernel: [_end+340620805/1069786896] ppp_async_push+0xf5/0x250 [ppp_async]
May 23 18:34:18 estel kernel: [uart_flush_buffer+170/240] uart_flush_buffer+0xaa/0xf0
May 23 18:34:18 estel kernel: [_end+340618814/1069786896] ppp_asynctty_wakeup+0x2e/0x60 [ppp_async]
May 23 18:34:18 estel kernel: [do_tty_hangup+1299/1472] do_tty_hangup+0x513/0x5c0
May 23 18:34:18 estel kernel: [worker_thread+566/992] worker_thread+0x236/0x3e0
May 23 18:34:18 estel kernel: [do_tty_hangup+0/1472] do_tty_hangup+0x0/0x5c0
May 23 18:34:18 estel kernel: [default_wake_function+0/48] default_wake_function+0x0/0x30
May 23 18:34:18 estel kernel: [ret_from_fork+6/20] ret_from_fork+0x6/0x14
May 23 18:34:18 estel kernel: [default_wake_function+0/48] default_wake_function+0x0/0x30
May 23 18:34:18 estel kernel: [worker_thread+0/992] worker_thread+0x0/0x3e0
May 23 18:34:18 estel kernel: [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10
May 23 18:34:18 estel kernel:
I can't check if it has been repoted in bugzilla as bugme.osdl.org shows
Software error:
Bugzilla is currently broken. Please try again later. If the problem persists [...]
But that's another problem :)
--
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 5824 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread