Re: unusual scheduling performance

[Dave Hansen <haveblue@us.ibm.com>]

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