lkml.org 
[lkml]   [2002]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: unusual scheduling performance
William Lee Irwin III wrote:
> On Mon, Nov 18, 2002 at 08:34:34AM -0800, Martin J. Bligh wrote:
>
>>1. make -j <what?>
>>2. profiles?
>>3. Can you try the latest set of NUMA sched patches posted by Eric Focht?
>
> (1) make -j64 bzImage
> (2) doesn't sound useful for load balancing
> (3) sure

I'm seeing the same thing. In my pagecache warmup test, I do 20 greps
to pull in a 10-gig fileset. Each grep works on 1/20th of the files.

For a long, long time, one the file set was warmed up, the time to do
the test took ~14 secdonds:
Average Real: 14.0824
Average User: 0.94055
Average Sys: 5.20875
Full profile here:
http://www.sr71.net/prof/grep/run-grep-warm-2.5.47-11-15-2002-15.21.31/

As of 2.5.47, it looks like this:
Average Real: 18.9168
Average User: 1.0073
Average Sys: 4.9918
Full profile here:
http://www.sr71.net/prof/grep/run-grep-warm-2.5.47-11-15-2002-15.58.02/

readprofile ticks
------------------
fast slow diff
page_cache_readahead: 93 82 -11
__generic_file_aio_read: 73 83 10
file_move: 52 86 34
dget_locked: 57 87 30
proc_pid_stat: 149 88 -61
ep_notify_file_close: 59 89 30
get_pid_list: 21 91 70
update_atime: 100 93 -7
get_unused_fd: 23 105 82
fget: 120 113 -7
dput: 100 120 20
get_empty_filp: 105 121 16
system_call: 113 129 16
rwsem_down_write_failed: 133 133
vfs_follow_link: 116 164 48
file_read_actor: 198 227 29
__fput: 178 241 63
radix_tree_lookup: 324 293 -31
atomic_dec_and_lock: 229 307 78
.text.lock.dec_and_lock: 111 331 220
try_to_wake_up: 374 374
kmap_atomic: 346 398 52
kunmap_atomic: 379 409 30
vfs_read: 440 431 -9
.text.lock.namei: 149 482 333
__d_lookup: 456 518 62
link_path_walk: 533 710 177
schedule: 1 1060 1059
do_generic_mapping_read: 1880 1846 -34
poll_idle: 2059 33416 31357
__copy_to_user: 94208 87678 -6530
total: 104173 132206 28033

So, schedule() is being called a _lot_ more. But, for some reason,
the slower one wasn't caught doing __copy_to_user() as much.

Bill, does this look like what you're seeing?
--
Dave Hansen
haveblue@us.ibm.com

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:31    [W:0.901 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site