sched: Rename sched.c as sched/core.c in comments and Documentation

1.7 What is sched_load_balance ?

--------------------------------

The kernel scheduler (kernel/sched.c) automatically load balances

The kernel scheduler (kernel/sched/core.c) automatically load balances

tasks.  If one CPU is underutilized, kernel code running on that

CPU will look for tasks on other more overloaded CPUs and move those

tasks to itself, within the constraints of such placement mechanisms

__rt_mutex_adjust_prio examines the result of rt_mutex_getprio, and if the

result does not equal the task's current priority, then rt_mutex_setprio

is called to adjust the priority of the task to the new priority.

Note that rt_mutex_setprio is defined in kernel/sched.c to implement the

Note that rt_mutex_setprio is defined in kernel/sched/core.c to implement the

actual change in priority.

It is interesting to note that __rt_mutex_adjust_prio can either increase

load of each of its member CPUs, and only when the load of a group becomes

out of balance are tasks moved between groups.

In kernel/sched.c, trigger_load_balance() is run periodically on each CPU

In kernel/sched/core.c, trigger_load_balance() is run periodically on each CPU

through scheduler_tick(). It raises a softirq after the next regularly scheduled

rebalancing event for the current runqueue has arrived. The actual load

balancing workhorse, run_rebalance_domains()->rebalance_domains(), is then run

the specifics and what to tune.

Architectures may retain the regular override the default SD_*_INIT flags

while using the generic domain builder in kernel/sched.c if they wish to

while using the generic domain builder in kernel/sched/core.c if they wish to

retain the traditional SMT->SMP->NUMA topology (or some subset of that). This

can be done by #define'ing ARCH_HASH_SCHED_TUNE.

But when you do the write-lock, you have to use the irq-safe version. 

For an example of being clever with rw-locks, see the "waitqueue_lock" 

handling in kernel/sched.c - nothing ever _changes_ a wait-queue from

handling in kernel/sched/core.c - nothing ever _changes_ a wait-queue from

within an interrupt, they only read the queue in order to know whom to

wake up. So read-locks are safe (which is good: they are very common

indeed), while write-locks need to protect themselves against interrupts.

           at process_kern.c:156

       #3  0x1006a052 in switch_to (prev=0x50072000, next=0x507e8000, last=0x50072000)

           at process_kern.c:161

       #4  0x10001d12 in schedule () at sched.c:777

       #4  0x10001d12 in schedule () at core.c:777

       #5  0x1006a744 in __down (sem=0x507d241c) at semaphore.c:71

       #6  0x1006aa10 in __down_failed () at semaphore.c:157

       #7  0x1006c5d8 in segv_handler (sc=0x5006e940) at trap_user.c:174

           at process_kern.c:161

       161       _switch_to(prev, next);

       (gdb)

       #4  0x10001d12 in schedule () at sched.c:777

       #4  0x10001d12 in schedule () at core.c:777

       777             switch_to(prev, next, prev);

       (gdb)

       #5  0x1006a744 in __down (sem=0x507d241c) at semaphore.c:71