Re: Scheduler fairness problem on 2.6 series

[Bill Davidsen]

Con Kolivas wrote:
> Prakash K. Cheemplavam wrote:
>
> > |
> > | I don't think it is the overhead. I rather think the way the kernel
> > | schedulers gives mpich and the cpu bound program  resources is unfair.
> >
> > Well, I don't know whether it helps, but I ran a profiler and these are
> > the functions which cause so much wasted CPU cycles when running 16
> > processes of my example with mpich:
> >
> > 124910    9.8170  vmlinux                  tcp_poll
> > 123356    9.6949  vmlinux                  sys_select
> > 85634     6.7302  vmlinux                  do_select
> > 71858     5.6475  vmlinux                  sysenter_past_esp
> > 62093     4.8801  vmlinux                  kfree
> > 51658     4.0600  vmlinux                  __copy_to_user_ll
> > 37495     2.9468  vmlinux                  max_select_fd
> > 36949     2.9039  vmlinux                  __kmalloc
> > 22700     1.7841  vmlinux                  __copy_from_user_ll
> > 14587     1.1464  vmlinux                  do_gettimeofday
> >
> > Is anything scheduler related?
>
>
> No
>
> It looks like your select timeouts are too short and when the cpu load 
> goes up they repeatedly timeout wasting cpu cycles.
> I quote from `man select_tut` under the section SELECT LAW:
>
> 1. You should always try use select without a timeout. Your program
>  should have nothing to do if there is no  data  available.  Code
>  that  depends  on timeouts is not usually portable and difficult
>  to debug.

There's a generalization which should confuse novice users... correctly 
used a timeout IS a debugging technique. Useful to detect when a peer 
has gone walkabout, as a common example.

Sounds as if the timeout is way too low here, however. Perhaps they are 
using it as poorly-done polling? In any case, not kernel misbehaviour.

--
   -bill davidsen (davidsen@xxxxxxx)
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/