From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Andrew Morton <akpm@osdl.org>
Cc: markw@osdl.org, linux-kernel@vger.kernel.org, Jens Axboe <axboe@suse.de>
Subject: Re: 2.6.5-rc3-mm4
Date: Sat, 03 Apr 2004 09:43:57 +1000 [thread overview]
Message-ID: <406DFABD.8070400@yahoo.com.au> (raw)
In-Reply-To: <20040402115601.24912093.akpm@osdl.org>
Andrew Morton wrote:
> markw@osdl.org wrote:
>
>>I reran DBT-2 to with ext2 and ext3 (in case you were still interested)
>> on my 4-way Xeon system with 60+ drives:
>> http://developer.osdl.org/markw/fs/dbt2_project_results.html
>>
>> Aside from the from the drop you're already aware of since 2.6.3, it
>> looks like DBT-2 takes another smaller hit after 2.6.5-rc3-mm2. Here's
>> a brief summary from the link above:
>
>
> The profile is interesting:
>
> 3671973 poll_idle 63309.8793
> 77750 __copy_from_user_ll 637.2951
> 64788 generic_unplug_device 487.1278
> 62968 DAC960_LP_InterruptHandler 336.7273
> 53908 finish_task_switch 361.7987
> 52947 __copy_to_user_ll 441.2250
> 29419 dm_table_unplug_all 439.0896
> 25947 __make_request 17.9938
> 18564 dm_table_any_congested 199.6129
> 13785 update_queue 104.4318
> 13498 try_to_wake_up 20.3590
> 12736 __wake_up 114.7387
> 12560 kmem_cache_alloc 163.1169
> 12221 .text.lock.sched 40.7367
>
> - There's a ton of idle time there.
>
> - The CPU scheduler is hurting. Nick and Ingo are patching up a storm to
> fix a similar problem which Jeremy Higdon is observing at 200,000
> IOs/sec. This will get better.
Versus this for 2.6.3:
12825181 poll_idle 221123.8103
219606 schedule 126.7201
194233 __copy_from_user_ll 1541.5317
191707 __copy_to_user_ll 1597.5583
149704 DAC960_LP_InterruptHandler 800.5561
120972 generic_unplug_device 822.9388
87891 __make_request 60.9931
49207 try_to_wake_up 74.5561
42647 do_anonymous_page 65.5100
Which looks like it is taking a lot longer (is it the same test?)
It is difficult to tell how idle each one is due to lack of total
ticks reported, but, copy_to/from_user is 3% the amount of idle
time in 2.6.3, while being 3.5% the amount of idle time in your
profile.
So 2.6.3 could be relatively more idle than -mm.
Do we know what the 2.6.3 regression is caused by? Or is it
likely to be the CPU scheduler?
next prev parent reply other threads:[~2004-04-03 0:07 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-01 10:05 2.6.5-rc3-mm4 Andrew Morton
2004-04-01 12:02 ` 2.6.5-rc3-mm4 Marc-Christian Petersen
2004-04-01 15:16 ` 2.6.5-rc3-mm4 Greg KH
2004-04-01 15:32 ` 2.6.5-rc3-mm4 Marc-Christian Petersen
2004-04-01 14:12 ` 2.6.5-rc3-mm4 Norberto Bensa
2004-04-02 1:35 ` 2.6.5-rc3-mm4 Joshua Kwan
2004-04-02 2:09 ` 2.6.5-rc3-mm4 Norberto Bensa
2004-04-01 23:12 ` 2.6.5-rc3-mm4 (compile stats) John Cherry
2004-04-02 19:04 ` 2.6.5-rc3-mm4 markw
2004-04-02 19:56 ` 2.6.5-rc3-mm4 Andrew Morton
2004-04-02 20:46 ` 2.6.5-rc3-mm4 markw
2004-04-02 23:43 ` Nick Piggin [this message]
2004-04-03 0:10 ` 2.6.5-rc3-mm4 Mark Wong
2004-04-03 0:12 ` 2.6.5-rc3-mm4 Nick Piggin
2004-04-06 15:20 ` 2.6.5-rc3-mm4 markw
-- strict thread matches above, loose matches on Subject: below --
2004-04-02 3:09 2.6.5-rc3-mm4 Sid Boyce
2004-04-03 11:08 ` 2.6.5-rc3-mm4 Sid Boyce
2004-04-04 1:15 2.6.5-rc3-mm4 Paul Blazejowski
2004-04-04 23:34 ` 2.6.5-rc3-mm4 Trond Myklebust
2004-04-05 1:25 ` 2.6.5-rc3-mm4 Paul Blazejowski
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=406DFABD.8070400@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=markw@osdl.org \
/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 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.