(BB: edited to include <litmus/litmus.h> to resolve compile error.)

Linux's post_schedule() scheduling class hook more closely matches
what SCHED2 is supposed to trace, namely any scheduling overhead after
the context switch. The prior trace points caught timers being armed
from finish_switch(), which is already included in the context switch
cost CXS.

(This patch essentially reverts 8fe2fb8bb1c1cd0194608bc783d0ce7029e8d869).

IPIs have some special cases where irq_enter() is not called. This
caused ft_irq_fired() to "miss" some rescheduling-related interrupts,
which in turn may cause outliers.

This patch makes sure ft_irq_fired() is called on scheduling-related
IPIs.

We don't want outliers due to soft IRQs, so let them mark ongoing
traces as "dirty" as well.

The LITMUS^RT-specific completion API complete_n() is no longer
required by the synchronous release code. Let's remove it; one less
modification of a core Linux file to maintain during rebasing.

Fixes a bug in Litmus where processor scheduling states
could become corrupted. Corruption can occur when a
just-forked thread is externally forced to be scheduled
by SCHED_LITMUS before this just-forked thread can complete
post-fork processing. Specifically, before schedule_tail()
has completed.

Enable kernel-style events (tracepoint) for Litmus. Litmus events
trace the same functions as the sched_trace_XXX(), but can be
enabled independently.

So, why another tracing infrastructure then:
- Litmus tracepoints can be recorded and analyzed together (single
  time reference) with all other kernel tracing events (e.g.,
  sched:sched_switch, etc.). It's easier to correlate the effects
  of kernel events on litmus tasks.

- It enables a quick way to visualize and process schedule traces
  using trace-cmd utility and kernelshark visualizer.
  Kernelshark lacks unit-trace's schedule-correctness checks, but
  it enables a fast view of schedule traces and it has several
  filtering options (for all kernel events, not only Litmus').

Whether to send IPIs and enqueue tasks on remote runqueues is
plugin-specific. The recent ttwu_queue() mechanism (by calling
ttwu_queue_remote()) interferes with Litmus plugin decisions.

Some notes:
* Litmus^RT scheduling class is the topmost scheduling class
  (above stop_sched_class).
* scheduler_ipi() function (e.g., in smp_reschedule_interrupt())
  may increase IPI latencies.
* Added path into schedule() to quickly re-evaluate scheduling
  decision without becoming preemptive again. This used to be
  a standard path before the removal of BKL.

Conflicts:
	Makefile
	arch/arm/kernel/calls.S
	arch/arm/kernel/smp.c
	arch/x86/include/asm/unistd_32.h
	arch/x86/kernel/smp.c
	arch/x86/kernel/syscall_table_32.S
	include/linux/hrtimer.h
	kernel/printk.c
	kernel/sched.c
	kernel/sched_fair.c

* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  signal: align __lock_task_sighand() irq disabling and RCU
  softirq,rcu: Inform RCU of irq_exit() activity
  sched: Add irq_{enter,exit}() to scheduler_ipi()
  rcu: protect __rcu_read_unlock() against scheduler-using irq handlers
  rcu: Streamline code produced by __rcu_read_unlock()
  rcu: Fix RCU_BOOST race handling current->rcu_read_unlock_special
  rcu: decrease rcu_report_exp_rnp coupling with scheduler