From: Andrew Morton <akpm@digeo.com>
To: Robert Macaulay <robert_macaulay@dell.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.5.57 IO slowdown with CONFIG_PREEMPT enabled
Date: Wed, 15 Jan 2003 11:18:34 -0800 [thread overview]
Message-ID: <20030115111834.41881823.akpm@digeo.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0301151106340.21210-100000@ping.us.dell.com>
Robert Macaulay <robert_macaulay@dell.com> wrote:
>
> In between 2.5.56 and 2.5.57 IO speeds have dropped if CONFIG_PREEMPT is
> set.
>
> The machine is a 4 processor Xeon with 8GB of RAM. The external storage is
> attached to the machine via qlogic 2200 HBAs using the qlogicfc driver.
> The filesystems on the external devices is reiserfs, mounted with noatime
> as the only change from defaults. The config file is attached below. The
> same config was used for both 2.5.56 and 2.5.57. The config has
> preemptable kernel enabled. I know preemption will lower your throughput,
> but it was enabled in 2.5.56, and speed was good.
>
I cannot reproduce this :(
Machine is a quad pIII Xeon, 4G of RAM (IDE starts bouncing above 4G),
writing four disks (2xIDE, 2xSCSI).
With CONFIG_PREEMPT=y:
3 1 1 1656 3224 3908 218564 0 0 0 76308 1545 705 1 86 13
3 1 1 1656 3784 3996 217920 0 0 0 74676 1529 736 0 86 14
3 1 1 1656 3024 4104 218388 0 0 0 71320 1538 614 0 86 13
4 0 2 1656 2496 3948 219104 0 0 0 73992 1536 687 0 88 12
3 1 1 1680 3652 4004 218004 0 24 0 74040 1524 647 0 88 12
3 1 1 1680 2972 4032 218596 32 0 48 78136 1547 688 0 87 13
oprofile says:
c01685f4 164 0.49068 mpage_writepages
c01e6a14 177 0.529575 journal_mark_dirty
c014c79c 182 0.544535 __block_prepare_write
c01ca90c 190 0.568471 balance_leaf
c01e676c 205 0.61335 do_journal_begin_r
c0131bf4 237 0.709093 generic_file_aio_write_nolock
c01de9b8 251 0.75098 is_leaf
c014c044 290 0.867666 __find_get_block
c01d03f0 442 1.32244 reiserfs_get_block
c01dec24 978 2.92613 search_by_key
c01dc8a0 1836 5.49322 leaf_paste_in_buffer
c01f88f8 2963 8.86515 __copy_from_user_ll
c0108a88 6235 18.6548 poll_idle
c011ad8c 11403 34.1172 __preempt_spin_lock
OK, that's similar to yours. Disabling preemption:
c01dccd0 576 0.490213 reiserfs_restore_prepared_buffer
c01dbf94 605 0.514894 journal_mark_dirty
c01dbcec 615 0.523404 do_journal_begin_r
c0147a9c 628 0.534468 __block_prepare_write
c01d3f58 637 0.542128 is_leaf
c012f004 658 0.56 generic_file_aio_write_nolock
c01c8828 873 0.742979 reiserfs_commit_write
c01473c4 1376 1.17106 __find_get_block
c01c5b90 1651 1.40511 reiserfs_get_block
c01d41c4 3496 2.97532 search_by_key
c01d1e40 6264 5.33106 leaf_paste_in_buffer
c01edc18 10115 8.60851 __copy_from_user_ll
c0108a58 21450 18.2553 poll_idle
c01c8afc 38908 33.1132 .text.lock.inode
And the I/O rate is the same. So all we've done here is to move the lock
contention from kernel/sched.c to fs/reiserfs/inode.c. It'll be
lock_kernel().
So hm. Confused. Could you please:
- double check everything.
- try booting with mem=4G? It could be that something broke and there is
bounce buffering happening above 4G - the regular kernel profiler often
will not show this.
- remove the cpu_relax() call from kernel/sched.c:__preempt_spin_lock()
Thanks.
BTW: here is ext2:
0 4 2 704 136696 13980 3904276 0 0 0 104848 1680 310 1 99 0
0 4 2 704 30336 14084 4009228 0 0 0 100836 1680 273 0 100 0
0 4 3 1716 5532 9848 4038584 0 1012 8 99888 1682 342 1 97 3
2 2 3 1716 5132 9956 4038788 0 0 0 97392 1685 307 0 100 0
1 3 3 1716 4996 10052 4038832 0 0 0 97276 1689 310 1 99 0
0 4 3 1716 8252 10160 4035436 0 0 4 100644 1691 321 0 98 2
2 2 3 1716 5176 10256 4038020 0 0 8 102432 1683 333 2 98 1
1 3 3 1716 7124 10348 4035804 0 0 0 112740 1691 354 0 100 0
c0134bcc 193 0.337094 __set_page_dirty_nobuffers
c0120bc0 194 0.338841 current_kernel_time
c019890c 249 0.434904 ext2_get_branch
c014c044 261 0.455863 __find_get_block
c0131bf4 265 0.46285 generic_file_aio_write_nolock
c01681bc 280 0.489049 mpage_writepage
c023ab18 300 0.523981 ide_outb
c01685f4 307 0.536207 mpage_writepages
c01305a4 314 0.548433 unlock_page
c0198cd8 372 0.649736 ext2_get_block
c01f88f8 8907 15.557 __copy_from_user_ll
c0108a88 39147 68.3743 poll_idle
So sweet.
next prev parent reply other threads:[~2003-01-15 19:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-15 17:36 Robert Macaulay
2003-01-15 18:01 ` Andrew Morton
2003-01-15 19:18 ` Andrew Morton [this message]
2003-01-15 22:12 ` Robert Macaulay
2003-01-15 22:33 ` Andrew Morton
2003-01-15 22:46 ` Robert Macaulay
2003-01-15 23:20 ` Robert Macaulay
2003-01-16 11:51 ` Andrew Morton
2003-01-16 16:14 ` Robert Macaulay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030115111834.41881823.akpm@digeo.com \
--to=akpm@digeo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robert_macaulay@dell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®