[lkml]   [2010]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Regression] Filesystem I/O is CPU-bound in rc7 and rc8
    While getting re-aquainted with perf, and after upgrading to the current
    version, I see that do_page_fault, unmap_vmas, get_page_from_freelist,
    handle_mm_fault, __do_fault and T.1339 tend to get the most time when the
    kernel is spinning.

    T.1339 is in this part of kallsyms:

    ,----< grep -E -C9 ^c1027750 /proc/kallsyms >
    | c10266a0 T sched_setscheduler_nocheck
    | c10266c0 T sched_setscheduler
    | c10266e0 t do_sched_setscheduler
    | c1026770 T sys_sched_setparam
    | c1026790 T sys_sched_setscheduler
    | c10267c0 T sched_fork
    | c1026900 T task_oncpu_function_call
    | c1026960 T print_cfs_rq
    | c1027640 T scheduler_tick
    | c1027750 t T.1339
    | c10277f0 T schedule_tail
    | c1027830 t ftrace_raw_output_sched_kthread_stop
    | c1027930 t ftrace_raw_output_sched_kthread_stop_ret
    | c1027a30 t ftrace_raw_output_sched_wait_task
    | c1027b40 t ftrace_raw_output_sched_switch
    | c1027c90 t ftrace_raw_output_sched_migrate_task
    | c1027da0 t ftrace_raw_output_sched_process_wait
    | c1027eb0 t ftrace_raw_output_sched_process_fork
    | c1027fc0 t ftrace_raw_output_sched_stat_runtime

    suggesting that T.1339 is part of sched.

    This leaves the impression that the issue is related to either
    scheduling or paging.

    I don't see any commits in the rc6..rc7 timeframe which stand out
    as likely suspects.

    James Cloos <> OpenPGP: 1024D/ED7DAEA6

     \ /
      Last update: 2010-02-17 21:39    [W:0.021 / U:217.540 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site