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.
Changes since 2.5.69-mm7:
-ipv6-compile-fix.patch
-sysfs_create_link-fix.patch
-subarch-circular-dependency-fix.patch
-genarch_clustered_io_apic.patch
-voyager_callout.patch
-sound-core-memalloc-build-fix.patch
-ppp-warning-fix.patch
-misc.patch
-large-dma_addr_t-PAE-only.patch
-3c59x-irq-fix.patch
-reiserfs-multiple-block-insertion.patch
-reiserfs_file_write-6.patch
-apm-module-fix.patch
-vmtruncate-PAGE_SIZE-fix.patch
-v4l-1.patch
-v4l-2.patch
-v4l-3.patch
-v4l-4.patch
-v4l-5.patch
-v4l-6.patch
-v4l-7.patch
-bttv-compile-fix.patch
-radeon-fb-64-bit-fix.patch
-cs4281-cleanup.patch
-stanford-memcy-size-fixes.patch
-BUG-to_BUG_ON.patch
-3c59x-id.patch
-suspend-asm-fix.patch
-handle-sparse-physical-apid-ids.patch
-put_page_testzero-fix.patch
-via-agp-fix.patch
-DAC960-oops-fix.patch
-it87-memset-fix.patch
Merged
+kmalloc_percpu-interface-change-warning-fix.patch
kmalloc_percpu() interface change
+ppc64-addnote-warning-fix.patch
+ppc64-fp-warning-fix.patch
+ppc64-do_signal32-fix.patch
+ppc64-xics-warning-fix.patch
+ppc64-prom-warning-fix.patch
+ppc64-compat-build-fix.patch
+ppc64-ioctl32-warning-fix-2.patch
+ppc64-setup-warning-fix.patch
+ppc64-traps-warning-fixes.patch
+ppc64-lpar-warning-fixes.patch
+tty_io-warning-fix.patch
+siocdevprivate_ioctl-warning-fix.patch
Compile warning massacre
+apm-set_cpus_allowed-fix.patch
Race fix.
+as-sync-async.patch
Anticipatory scheduler change
-sched-2.5.68-B2.patch
-sched_idle-typo-fix.patch
-kgdb-ga-idle-fix.patch
-sched-2.5.64-D3.patch
The HT scheduler (and its fallout) broke. It needs updating.
+slab-reclaimable-accounting.patch
+slab-reclaimable-accounting-fs.patch
Account for reclaimable slab pages in slab itself (for vm_enough_memory)
+aio-06-bread_wq-fix.patch
AIO fixlet
+misc2.patch
Misc fixes (mainly more warnings)
+io_stats-documentation.patch
Document the disk accounting stats
+voyager-do_fork-fix.patch
Fix voyager crash
+cpia-fp-removal.patch
Don't use float in kernel
+vfsmount_lock.patch
+lockfree-lookup_mnt.patch
Take some pressure off dcache_lock.
All 129 patches:
linus.patch
mm.patch
add -mmN to EXTRAVERSION
kgdb-ga.patch
kgdb stub for ia32 (George Anzinger's one)
kmalloc_percpu-interface-change.patch
kmalloc_percpu: interface change.
kmalloc_percpu-interface-change-warning-fix.patch
nail a warning
irqreturn-drivers-net.patch
slab-magazine-layer.patch
magazine layer for slab
slab-magazine-tuning.patch
tuning for slab-magazine-layer.patch
slabinfo-rework.patch
new statistics for slab
aio-random-cleanups.patch
config_spinline.patch
uninline spinlocks for profiling accuracy.
ppc64-ioctl-pci-update.patch
From: Anton Blanchard <[email protected]>
Subject: ppc64 stuff
ppc64-reloc_hide.patch
ppc64-aio-32bit-emulation.patch
32/64bit emulation for aio
ppc64-scruffiness.patch
Fix some PPC64 compile warnings
ppc64-xics-irq-fix.patch
PPC64 irq return fix
ppc64-addnote-warning-fix.patch
Squash warning in ppc64 addnote tool
ppc64-fp-warning-fix.patch
Squash implicit declaration warning in ppc64 align.c
ppc64-do_signal32-fix.patch
ppc64 do_signal32 warning fix
ppc64-xics-warning-fix.patch
Squash warning in ppc64 xics.c
ppc64-prom-warning-fix.patch
Unused variables in ppc64 prom.c
ppc64-compat-build-fix.patch
ppc64 build fix
ppc64-ioctl32-warning-fix-2.patch
ppc64 ioctl32 warning fix
ppc64-setup-warning-fix.patch
nail warnings in arch/ppc64/kernel/setup.c
ppc64-traps-warning-fixes.patch
arch/ppc64/kernel/traps.c warning fixes
ppc64-lpar-warning-fixes.patch
ppc64: more warning fixes
tty_io-warning-fix.patch
tty_io warning fix
siocdevprivate_ioctl-warning-fix.patch
siocdevprivate_ioctl warning fix
aic-errno-removal.patch
aic7xxx build fix
aic-non-i386-build-fix.patch
aic7xxx non-i386 build fix
aic7xxx-fixes.patch
sym-do-160.patch
make the SYM driver do 160 MB/sec
irqreturn-snd-via-fix.patch
via sound irqreturn fix
irq_cpustat-cleanup.patch
irq_cpustat cleanup
config-PAGE_OFFSET.patch
Configurable kenrel/user memory split
irq-check-rate-limit.patch
IRQs: handle bad return values from handlers
irq_desc-others.patch
Fix up irq_desc initialisation for non-ia32
dcache_lock-vs-tasklist_lock-take-3.patch
Fix dcache_lock/tasklist_lock ranking bug
apm-set_cpus_allowed-fix.patch
APM does unsafe conditional set_cpus_allowed
buffer-debug.patch
buffer.c debugging
ext3-truncate-ordered-pages.patch
ext3: explicitly free truncated pages
VM_RESERVED-check.patch
VM_RESERVED check
reiserfs-inode-attribute-support.patch
reiserfs: inode attributes support.
rcu-stats.patch
RCU statistics reporting
ext3-journalled-data-assertion-fix.patch
Remove incorrect assertion from ext3
make-KOBJ_NAME-match-BUS_ID_SIZE.patch
Make KOBJ_NAME_LEN match BUS_ID_SIZE
xirc2ps_cs-irqreturn-fix.patch
xirc2ps_cs irq return fix
ide_setting_sem-fix.patch
readdir-return-value-fix.patch
Fix readdir error return value
reslabify-pgds-and-pmds.patch
re-slabify i386 pgd's and pmd's
linux-isp.patch
isp-update-1.patch
list_del-debug.patch
list_del debug check
airo-schedule-fix.patch
airo.c: don't sleep in atomic regions
synaptics-mouse-support.patch
Add Synaptics touchpad tweaking to psmouse driver
inode-unhashing-fix-2.patch
Don't remove inode from hash until filesystem has deleted it
resurrect-batch_requests.patch
bring back the batch_requests function
kblockd.patch
Create `kblockd' workqueue
cfq-infrastructure.patch
elevator-completion-api.patch
elevator completion API
as-iosched.patch
anticipatory I/O scheduler
as-proc-read-write.patch
AS: pgbench improvement
as-discrete-read-fifo-batches.patch
AS: discrete read fifo batches
as-sync-async.patch
AS sync/async batches
unplug-use-kblockd.patch
Use kblockd for running request queues
cfq-2.patch
CFQ scheduler, #2
cfq-iosched-dyn.patch
CFQ: update to rq-dyn API
unmap-page-debugging.patch
unmap unused pages for debugging
fremap-all-mappings.patch
Make all executable mappings be nonlinear
sched-numa-warning-fix.patch
scheduler warning fix for NUMA
acpi-irq-ret-fix.patch
acpi irq return value fix
sound-irq-hack.patch
show_task-free-stack-fix.patch
show_task() fix and cleanup
put_task_struct-debug.patch
ia32-mknod64.patch
mknod64 for ia32
ext2-64-bit-special-inodes.patch
ext2: support for 64-bit device nodes
ext3-64-bit-special-inodes.patch
ext3: support for 64-bit device nodes
64-bit-dev_t-kdev_t.patch
64-bit dev_t and kdev_t
oops-dump-preceding-code.patch
i386 oops output: dump preceding code
lockmeter.patch
slab-reclaimable-accounting.patch
slab: account for reclaimable caches
slab-reclaimable-accounting-fs.patch
mark shrinkable slabs as being reclaimable
security-process-attribute-api.patch
Process Attribute API for Security Modules
proc-pid-attr-fix.patch
Process Attribute API for Security Modules (fixlet)
proc-pid-security-labels.patch
/proc/pid inode security labels
time-interpolation-infrastructure.patch
improved core support for time-interpolation
time-interpolation-infrastructure-fix.patch
make timer interpolation patch compile
thread-info-in-task_struct.patch
allow thread_info to be allocated as part of task_struct
reinstate-task-freeing-hack-for-ia64.patch
reinstate lame task_struct (non)-refcounting hack/fix
ext3-no-bkl.patch
journal_dirty_metadata-speedup.patch
journal_get_write_access-speedup.patch
ext3-concurrent-block-inode-allocation.patch
Subject: [PATCH] concurrent block/inode allocation for EXT3
ext3-orlov-approx-counter-fix.patch
Fix orlov allocator boundary case
ext3-concurrent-block-allocation-fix-1.patch
ext3-concurrent-block-allocation-hashed.patch
Subject: Re: [PATCH] concurrent block/inode allocation for EXT3
reboot_on_bsp.patch
kexec-revert-NORET_TYPE.patch
apic_shutdown.patch
i8259-shutdown.patch
hwfixes-x86kexec.patch
kexec-warning-fixes-2.patch
CONFIG_FUTEX.patch
FUTEX support should be optional
CONFIG_EPOLL.patch
eventpollfs configuration option
invalidate_mmap_range.patch
Interface to invalidate regions of mmaps
devpts-xattr-handler.patch
devpts xattr handler for security labels 2.5.69-bk
unregister_netdev-cleanup.patch
vt8237.patch
vt8237 IDE support
aio-01-retry.patch
AIO: Core retry infrastructure
aio-01-retry-cleanup.patch
aio trivia
aio-02-lockpage_wq.patch
AIO: Async page wait
aio-03-fs_read.patch
AIO: Filesystem aio read
aio-04-buffer_wq.patch
AIO: Async buffer wait
aio-05-fs_write.patch
AIO: Filesystem aio write
aio-06-bread_wq.patch
AIO: Async block read
aio-06-bread_wq-fix.patch
aio-07-ext2getblk_wq.patch
AIO: Async get block for ext2
aio-poll.patch
aio_poll
aio-poll-cleanup.patch
aio-poll: don't put extern decls in .c!
overcommit-root-margin.patch
overcommit root margin
rpc-ifdef-fix.patch
net/sunrpc/sunrpc_syms.c typo fix
notify_count-for-de_thread.patch
add notify_count for de_thread
extend-check_valid_hugepage_range.patch
rename check_valid_hugepage_range()
misc2.patch
misc fixes
io_stats-documentation.patch
Documentation for disk iostats
voyager-do_fork-fix.patch
do_fork fixes for voyager x86 subarch
cpia-fp-removal.patch
Remove floating point use in cpia.c
vfsmount_lock.patch
From: Maneesh Soni <[email protected]>
Subject: [patch 1/2] vfsmount_lock
lockfree-lookup_mnt.patch
lockfree lookup_mnt
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?
[email protected]
Lycos Europe - NOC France
On Thu, 22 May 2003 02:16:52 -0700
Andrew Morton <[email protected]> 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.
|
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
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;
/*
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andrew Morton <[email protected]> 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 | [email protected]
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-----
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 :-)
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
>> > 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.
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
Paul Larson <[email protected]> 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.
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
[email protected]
-----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-----
On Thu, 2003-05-22 at 15:14, Andrew Morton wrote:
> Paul Larson <[email protected]> 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
> 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 ;-)
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
[email protected]
>> 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.
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
> 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
On Thu, 22 May 2003 02:16:52 -0700
Andrew Morton <[email protected]> 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 :)
--