kernel:sched: LOAD_FREQ (4*HZ+61) avoids loadavg Moire

http://ripke.com/loadavg/moire

LOAD_FREQ is (5*HZ+1) to avoid high load average when idle.

Tests suggest (4*HZ+61) for a better distribution.

With some seconds based load (like SSL heartbeats)
and LOAD_FREQ at (5*HZ+1) we see Moire patterns like inverse sawtooth,
since 2 or 3 probes hit the jobs (load increases quickly),
followed by several probes missing it.

A 4.61 sec interval gives optimal distribution over when within a
second a probe is taken, as .61 is close to golden ratio phi 1.618...
(test in http://ripke.com/goldenratio.c).

12*4.61 = 55.32 secs is still close to a minute,
and 13*4.61=59.93 is even closer than the current 12*5.01=60.12
(with exponents EXP_x adjusted to a ratio of 13 instead of 12).
smp: Add generic smpboot facility

Thomas Gleixner's generic-idle patches:

smp: Add task_struct argument to __cpu_up()
	Preparatory patch to make the idle thread allocation for secondary
	cpus generic.

smp: Add generic smpboot facility
	Start a new file, which will hold SMP and CPU hotplug related generic
	infrastructure.

smp: Provide generic idle thread allocation
	All SMP architectures have magic to fork the idle task and to store it
	for reusage when cpu hotplug is enabled. Provide a generic
	infrastructure for it.
	Create/reinit the idle thread for the cpu which is brought up in the
	generic code and hand the thread pointer to the architecture code via
	__cpu_up().
	Note, that fork_idle() is called via a workqueue, because this
	guarantees that the idle thread does not get a reference to a user
	space VM. This can happen when the boot process did not bring up all
	possible cpus and a later cpu_up() is initiated via the sysfs
	interface. In that case fork_idle() would be called in the context of
	the user space task and take a reference on the user space VM.

arm: Use generic idle thread allocation

smp, idle: Allocate idle thread for each possible cpu during boot
	percpu areas are already allocated during boot for each possible cpu.
	percpu idle threads can be considered as an extension of the percpu areas,
	and allocate them for each possible cpu during boot.

	This will eliminate the need for workqueue based idle thread allocation.
	In future we can move the idle thread area into the percpu area too.

	[ tglx: Moved the loop into smpboot.c and added an error check when
	the init code failed to allocate an idle thread for a cpu which
	should be onlined ]

smpboot, idle: Optimize calls to smp_processor_id() in idle_threads_init()
	While trying to initialize idle threads for all cpus, idle_threads_init()
	calls smp_processor_id() in a loop, which is unnecessary. The intent
	is to initialize idle threads for all non-boot cpus. So just use a variable
	to note the boot cpu and use it in the loop.

kthread: Implement park/unpark facility
	To avoid the full teardown/setup of per cpu kthreads in the case of
	cpu hot(un)plug, provide a facility which allows to put the kthread
	into a park position and unpark it when the cpu comes online again.

smpboot: Provide infrastructure for percpu hotplug threads
	Provide a generic interface for setting up and tearing down percpu
	threads.

	On registration the threads for already online cpus are created and
	started. On deregistration (modules) the threads are stoppped.

	During hotplug operations the threads are created, started, parked and
	unparked. The datastructure for registration provides a pointer to
	percpu storage space and optional setup, cleanup, park, unpark
	functions. These functions are called when the thread state changes.

	Each implementation has to provide a function which is queried and
	returns whether the thread should run and the thread function itself.

	The core code handles all state transitions and avoids duplicated code
	in the call sites.

	[ paulmck: Preemption leak fix ]

hotplug: Fix UP bug in smpboot hotplug code
	Because kernel subsystems need their per-CPU kthreads on UP systems as
	well as on SMP systems, the smpboot hotplug kthread functions must be
	provided in UP builds as well as in SMP builds.  This commit therefore
	adds smpboot.c to UP builds and excludes irrelevant code via #ifdef.

softirq: Use hotplug thread infrastructure

watchdog: Use hotplug thread infrastructure

rcu: Use smp_hotplug_thread facility for RCUs per-CPU kthread
	Bring RCU into the new-age CPU-hotplug fold by modifying RCU's per-CPU
	kthread code to use the new smp_hotplug_thread facility.

	[ tglx: Adapted it to use callbacks and to the simplified rcu yield ]

smpboot: Allow selfparking per cpu threads
	The stop machine threads are still killed when a cpu goes offline. The
	reason is that the thread is used to bring the cpu down, so it can't
	be parked along with the other per cpu threads.

	Allow a per cpu thread to be excluded from automatic parking, so it
	can park itself once it's done

	Add a create callback function as well.

kthread: Prevent unpark race which puts threads on the wrong cpu
	The smpboot threads rely on the park/unpark mechanism which binds per
	cpu threads on a particular core. Though the functionality is racy:

	CPU0	       	 	CPU1  	     	    CPU2
	unpark(T)				    wake_up_process(T)
	  clear(SHOULD_PARK)	T runs
				leave parkme() due to !SHOULD_PARK
	  bind_to(CPU2)		BUG_ON(wrong CPU)

	We cannot let the tasks move themself to the target CPU as one of
	those tasks is actually the migration thread itself, which requires
	that it starts running on the target cpu right away.

	The solution to this problem is to prevent wakeups in park mode which
	are not from unpark(). That way we can guarantee that the association
	of the task to the target cpu is working correctly.

	Add a new task state (TASK_PARKED) which prevents other wakeups and
	use this state explicitly for the unpark wakeup.

	Peter noticed: Also, since the task state is visible to userspace and
	all the parked tasks are still in the PID space, its a good hint in ps
	and friends that these tasks aren't really there for the moment.

	The migration thread has another related issue.

	CPU0	      	     	 CPU1
	Bring up CPU2
	create_thread(T)
	park(T)
	 wait_for_completion()
				 parkme()
				 complete()
	sched_set_stop_task()
				 schedule(TASK_PARKED)

	The sched_set_stop_task() call is issued while the task is on the
	runqueue of CPU1 and that confuses the hell out of the stop_task class
	on that cpu. So we need the same synchronizaion before
	sched_set_stop_task().

kthread_worker: reorganize to prepare for flush_kthread_work() reimplementation
	Make the following two non-functional changes.

	* Separate out insert_kthread_work() from queue_kthread_work().

	* Relocate struct kthread_flush_work and kthread_flush_work_fn()
	  definitions above flush_kthread_work().

	v2: Added lockdep_assert_held() in insert_kthread_work() as suggested
	    by Andy Walls.

	Signed-off-by: Tejun Heo <tj@kernel.org>
	Acked-by: Andy Walls <awalls@md.metrocast.net>

kthread_worker: reimplement flush_kthread_work() to allow freeing the work item being executed
	kthread_worker provides minimalistic workqueue-like interface for
	users which need a dedicated worker thread (e.g. for realtime
	priority).  It has basic queue, flush_work, flush_worker operations
	which mostly match the workqueue counterparts; however, due to the way
	flush_work() is implemented, it has a noticeable difference of not
	allowing work items to be freed while being executed.

	While the current users of kthread_worker are okay with the current
	behavior, the restriction does impede some valid use cases.  Also,
	removing this difference isn't difficult and actually makes the code
	easier to understand.

	This patch reimplements flush_kthread_work() such that it uses a
	flush_work item instead of queue/done sequence numbers.

stop_machine: Store task reference in a separate per cpu variable
	To allow the stopper thread being managed by the smpboot thread
	infrastructure separate out the task storage from the stopper data
	structure.

stop_machine: Use smpboot threads
	Use the smpboot thread infrastructure. Mark the stopper thread
	selfparking and park it after it has finished the take_cpu_down()
	work.

stop_machine: Mark per cpu stopper enabled early
	commit 14e568e78 (stop_machine: Use smpboot threads) introduced the
	following regression:

	Before this commit the stopper enabled bit was set in the online
	notifier.

	CPU0				CPU1
	cpu_up
					cpu online
	hotplug_notifier(ONLINE)
	  stopper(CPU1)->enabled = true;
	...
	stop_machine()

	The conversion to smpboot threads moved the enablement to the wakeup
	path of the parked thread. The majority of users seem to have the
	following working order:

	CPU0				CPU1
	cpu_up
					cpu online
	unpark_threads()
	  wakeup(stopper[CPU1])
	....
					stopper thread runs
					  stopper(CPU1)->enabled = true;
	stop_machine()

	But Konrad and Sander have observed:

	CPU0				CPU1
	cpu_up
					cpu online
	unpark_threads()
	  wakeup(stopper[CPU1])
	....
	stop_machine()
					stopper thread runs
					  stopper(CPU1)->enabled = true;

	Now the stop machinery kicks CPU0 into the stop loop, where it gets
	stuck forever because the queue code saw stopper(CPU1)->enabled ==
	false, so CPU0 waits for CPU1 to enter stomp_machine, but the CPU1
	stopper work got discarded due to enabled == false.

	Add a pre_unpark function to the smpboot thread descriptor and call it
	before waking the thread.

	This fixes the problem at hand, but the stop_machine code should be
	more robust. The stopper->enabled flag smells fishy at best.

	Thanks to Konrad for going through a loop of debug patches and
	providing the information to decode this issue.

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
mach-msm: don't enforce compiling run_queue_stats module

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
mach-msm: Introduce Dynamic hotplug driver for MSM

Introduce a dynamic hotplug driver to automatically online/offline
CPUs proportional to load.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
cpufreq: update policy->util directly

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
dyn_hotplug: relax conditions for hotplug

- reduce hot-un-plug lock to 3 sec
- increase hot-plug lock to 1.5 sec
- increase up_threshold to 80

- consider max_load of busiest CPU instead of avg_load

- reset 'up_timer' if cpu0_freq below cpu0_max_freq
  AND 'load' below 'up_threshold'

Signed-off-by: moddingg33k <moddingg33k@t-online.de>