Log printk events to the uncached buffer. If a reset occurs
and printk data is still present in the cache, information will
be lost. This doesn't store the actual printk, but it at least
gives information on who the last caller was.
Change-Id: If1bd414a44b19b45c157d23a7ddde8f16b30e780
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Trevor Bourget <tbourget@codeaurora.org>
* changes:
irq: irqdomain: Add API to find free irq range
arm: gic: Check for error code on irq_domain_add
irq: irqdomain: Change irq_domain_add to detect errors
arm: gic: Register irqdomain after adding it
irq: irqdomain: Add support for dynamic irq_desc allocations
When registering irq chip drivers, one common requirement is to
specify the irq_domain irq_base and nr_irq. These fields represent
the system wide logical interrupt range the domain occupies.
For systems with only one interrupt controller, it's trivial to
know these values. But for systems with several irq chip drivers,
it becomes painful to keep track of interrupt ranges in platform
defines. These create needless compile time dependencies, of
which the Device Tree aims to solve.
irq_alloc_desc() can search for a free irq, but is very
inefficient for determining the availability of large ranges.
Additionally, some irq chip drivers allocate irq descriptors
lazily. For example, portions of the Device Tree may not be parsed
until a particular bus is probed. But of_irq_init() is intended to
be run at init time, and this is a natural time to allocate irq
domains. Thus by the time we allocate our irq descriptors, we already
need to know a range of acceptable irqs to use for the domain.
To solve these problems, let's introduce
irq_domain_find_free_range(), which will return to the caller the
first available irq domain range not used already by the system.
This range can then be specified with irq_domain_add().
Change-Id: I8b0f5d25b173c76b8fc5d4f46b3fe9c6bf5c3c8f
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
It should not be valid to add an irq_domain with a logical irq
range that overlaps with another already registered to the
system. Return an error on such an occurrence.
This change also inherently sorts the irq_domains by logical
irq_base as they are added.
Change-Id: Idef697dbe4584d783703d053fbf09f1b17e62ab0
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
The current irq_domain_add() design assumes the underlying
irq_descs are valid when irq_domain_add() is called. It also
assumes that every hwirq enlisted in the irq_domain is valid.
Often, these assumptions are not correct.
Typically, irq_domain_add() is called at board_init time, but
sometimes interrupt chip drivers are not initialized until an
underlying bus is probed. When using SPARSE_IRQ, it's quite
natural to hold off allocating irq_descs until the board
topology specifies them as included.
And in such device topologies, there's no guarantee that chip
interrupt numbers will be contiguous. For example, each hwirq may
map to a particular device, but that device may or may not be
present in the actual hardware configuration. In order to support
this, we need the concept of an irq_domain that supports holes
in it.
In order to solve these problems, let's break the irq_domain
creation from the irq registration process. The irq_domain
creation can occur at init time and then have no dependencies. An
interrupt is not 'registered' with the domain until its resources
have already been allocated by the chip driver. For simple cases,
an additional API is provided to register the entire
logical irq_domain range to provide feature parity with what
already exists.
Change-Id: Ie3340d07ba8663196dc87d1185e3bb7fbed4be4d
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
gcc incorrectly states that the variable "fmt" is uninitialized when
CC_OPITMIZE_FOR_SIZE is set.
Instead of just blindly setting fmt to NULL, the code is cleaned up
a little to be a bit easier for humans to follow, as well as gcc
to know the variables are initialized.
Change-Id: Ia5fb9cc6be8eadae9af3a5636a2459ed7cd48662
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
* changes:
Revert "cpu-hotplug: Add the function 'cpu_hotplug_inprogress'"
Revert "printk: Don't allow cpu to get console lock during hotplugging"
Revert "partition_sched_domains: Do not destroy old sched domain on cpu_up"
This reverts commit 3d321a3570.
Since sched domains are allocated dynamically now these
changes are N/A for 3.0. Hence the revert.
Change-Id: I0059a4384c871815c01455d4b6f5c8be582a5d73
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
This reverts commit 2aba4e8b5e.
Since sched domains are allocated dynamically now these
changes are N/A for 3.0. Hence the revert.
Change-Id: Ic6455ac02afd4191dc071343ebc303ab68df2bf9
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
This reverts commit e0473b4aaf.
Since sched domains are allocated dynamically now, these
changes are N/A for 3.0. Hence the revert.
Change-Id: I3ac329f298107f4ebdee6a1aab771d2be8ca5f5c
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
It can happen that the scheduler tick stops on cpu 0 but keeps
running on some other cpu. Make the cpu in-charge of updating
the jiffies also update the rq_stats.
Change-Id: Idb1a8132bd96500c68c516b4a99663965cec28e1
Signed-off-by: Amar Singhal <asinghal@codeaurora.org>
Interrupt controllers can have non-zero starting value for h/w irq numbers.
Adding support in irq_domain allows the domain hwirq numbering to match
the interrupt controllers' numbering.
As this makes looping over irqs for a domain more complicated, add loop
iterators to iterate over all hwirqs and irqs for a domain.
Change-Id: I64774aea2f3efb883fe11e9f6161970f7e7dc0fc
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Reviewed-by: Jamie Iles <jamie@jamieiles.com>
Tested-by: Thomas Abraham <thomas.abraham@linaro.org>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Trilok Soni <tsoni@codeaurora.org>
The commit 1e7c5fd breaks the build which gets fixed in the
next commit 32cffdd.
commit 1e7c5fd29487ee88cb3abac945bafa60ae026146
Author: Marc Zyngier <marc.zyngier@arm.com>
Date: Fri Sep 30 10:48:47 2011 +0100
genirq: percpu: allow interrupt type to be set at enable time
As request_percpu_irq() doesn't allow for a percpu interrupt to have
its type configured (it is generally impossible to configure it on all
CPUs at once), add a 'type' argument to enable_percpu_irq().
This allows some low-level, board specific init code to be switched to
a generic API.
[ tglx: Added WARN_ON argument ]
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit 32cffdde4a3ee6c2d9e0f0a94edecf1a9ce7586b
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Tue Oct 4 18:43:57 2011 +0200
genirq: Fix fatfinered fixup really
Putting the argument inside the quote does not really help.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Change-Id: I1c9e58dd8788b5515f183ec169975d48a329b339
[tsoni@codeaurora.org: Fixup MSM build failure]
Signed-off-by: Trilok Soni <tsoni@codeaurora.org>
The ARM GIC interrupt controller offers per CPU interrupts (PPIs),
which are usually used to connect local timers to each core. Each CPU
has its own private interface to the GIC, and only sees the PPIs that
are directly connect to it.
While these timers are separate devices and have a separate interrupt
line to a core, they all use the same IRQ number.
For these devices, request_irq() is not the right API as it assumes
that an IRQ number is visible by a number of CPUs (through the
affinity setting), but makes it very awkward to express that an IRQ
number can be handled by all CPUs, and yet be a different interrupt
line on each CPU, requiring a different dev_id cookie to be passed
back to the handler.
The *_percpu_irq() functions is designed to overcome these
limitations, by providing a per-cpu dev_id vector:
int request_percpu_irq(unsigned int irq, irq_handler_t handler,
const char *devname, void __percpu *percpu_dev_id);
void free_percpu_irq(unsigned int, void __percpu *);
int setup_percpu_irq(unsigned int irq, struct irqaction *new);
void remove_percpu_irq(unsigned int irq, struct irqaction *act);
void enable_percpu_irq(unsigned int irq);
void disable_percpu_irq(unsigned int irq);
The API has a number of limitations:
- no interrupt sharing
- no threading
- common handler across all the CPUs
Once the interrupt is requested using setup_percpu_irq() or
request_percpu_irq(), it must be enabled by each core that wishes its
local interrupt to be delivered.
Based on an initial patch by Thomas Gleixner.
Change-Id: I3e3d0f36e04added105753d30b2ef07e3d9d6a56
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1316793788-14500-2-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
[kumarrav@codeaurora.org: fixup manage.c merge conflict]
Signed-off-by: Ravi Kumar <kumarrav@codeaurora.org>
Interrupt descriptors can be allocated from modules. The interrupts
are used by other modules, but we have no refcount on the module which
provides the interrupts and there is no way to establish one on the
device level as the interrupt using module is agnostic to the fact
that the interrupt is provided by a module rather than by some builtin
interrupt controller.
To prevent removal of the interrupt providing module, we can track the
owner of the interrupt descriptor, which also provides the relevant
irq chip functions in the irq descriptor.
request/setup_irq() can now acquire a refcount on the owner module to
prevent unloading. free_irq() drops the refcount.
Change-Id: I132df8e65d4e01db4f15dba0868607c7cdd33e14
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Link: http://lkml.kernel.org/r/20110711101731.GA13804@Chamillionaire.breakpoint.cc
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ravi Kumar <kumarrav@codeaurora.org>
When performing cpu hotplug tests the kernel printk log buffer gets flooded
with pointless "Switched to NOHz mode..." messages. Especially when afterwards
analyzing a dump this might have removed more interesting stuff out of the
buffer.
Assuming that switching to NOHz mode simply works just remove the printk.
Change-Id: I1746f8c0119a512055716c3fd77a966b735ca49b
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Link: http://lkml.kernel.org/r/20110823112046.GB2540@osiris.boeblingen.de.ibm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jeff Ohlstein <johlstei@codeaurora.org>
During some CPU power modes entered during idle, hotplug and
suspend, peripherals located in the CPU power domain, such as
the GIC, localtimers, and VFP, may be powered down. Add a
notifier chain that allows drivers for those peripherals to
be notified before and after they may be reset.
Signed-off-by: Colin Cross <ccross <at> android.com>
[santosh.shilimkar <at> ti.com: Rebased against 3.1-rc3]
Signed-off-by: Santosh Shilimkar <santosh.shilimkar <at> ti.com>
Tested-by: Kevin Hilman <khilman <at> ti.com>
Change-Id: I6e076344b268869d12033f57321f3e7cf23b05e8
Signed-off-by: Ashwin Chaugule <ashwinc@codeaurora.org>
This reverts commit 7ef4dbaa2a.
Revert "power: wakelock: BUG if wakelock is taken very late"
This reverts commit 57b34bbdca.
Change-Id: Ie1288b5e6c899ac4419c55b91cb024b8093b5ffe
Signed-off-by: Patrick Cain <pcain@codeaurora.org>
Currently the __remove_hrtimer function attempts to reprogram the
clockevent device so that we don't wake up unnecessarily from a timer we
have deleted. However, it does the reprogramming before actually
removing the timer in question from the timerqueue, so it turns into a
noop. This causes us to have an extra wakeup every time we remove the
timer that fires this. This is especially noticeable when the system
goes idle and we switch to NOHZ mode, as the system will always wakeup
one extra time when the system tick is removed.
Change-Id: If8656bbf85694228f279923fa86bd798d23e0f49
Signed-off-by: Jeff Ohlstein <johlstei@codeaurora.org>
* common/android-3.0: (570 commits)
misc: remove kernel debugger core
ARM: common: fiq_debugger: dump sysrq directly to console if enabled
ARM: common: fiq_debugger: add irq context debug functions
net: wireless: bcmdhd: Call init_ioctl() only if was started properly for WEXT
net: wireless: bcmdhd: Call init_ioctl() only if was started properly
net: wireless: bcmdhd: Fix possible memory leak in escan/iscan
cpufreq: interactive governor: default 20ms timer
cpufreq: interactive governor: go to intermediate hi speed before max
cpufreq: interactive governor: scale to max only if at min speed
cpufreq: interactive governor: apply intermediate load on current speed
ARM: idle: update idle ticks before call idle end notifier
input: gpio_input: don't print debounce message unless flag is set
net: wireless: bcm4329: Skip dhd_bus_stop() if bus is already down
net: wireless: bcmdhd: Skip dhd_bus_stop() if bus is already down
net: wireless: bcmdhd: Improve suspend/resume processing
net: wireless: bcmdhd: Check if FW is Ok for internal FW call
tcp: Don't nuke connections for the wrong protocol
ARM: common: fiq_debugger: make uart irq be no_suspend
net: wireless: Skip connect warning for CONFIG_CFG80211_ALLOW_RECONNECT
mm: avoid livelock on !__GFP_FS allocations
...
Conflicts:
arch/arm/mm/cache-l2x0.c
arch/arm/vfp/vfpmodule.c
drivers/mmc/core/host.c
kernel/power/wakelock.c
net/bluetooth/hci_event.c
Signed-off-by: Bryan Huntsman <bryanh@codeaurora.org>
This reverts commit 7ef4dbaa2a.
Revert "power: wakelock: BUG if wakelock is taken very late"
This reverts commit 57b34bbdca.
Change-Id: Id4e05b191cf7781b8e0d0bed42f1c136b1ac428e
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Currently we reset msm_suspend_check_done in resume_noirq and set it
in the suspend_noirq stage right after the wakelock checks are done.
An issue is discovered recently that a wakelock can be held much earlier
in the resume sequence - a tasklet was scheduled right in the arch specifc
resume path, and this tasklet was run as soon as local interrupt was
enabled (the I bit in the CPSR for arm processors). The tasklet endedup
grabbing a wakelock thus causing a BUG.
To avoid this situation reset msm_suspend_check_done before enabling local
interrupts using the syscore ops.
Change-Id: I12766cb759134185e9727829f71893934492cc5f
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
commit bcd5cff7216f9b2de0a148cc355eac199dc6f1cf upstream.
There's a lock inversion between the cputimer->lock and rq->lock;
notably the two callchains involved are:
update_rlimit_cpu()
sighand->siglock
set_process_cpu_timer()
cpu_timer_sample_group()
thread_group_cputimer()
cputimer->lock
thread_group_cputime()
task_sched_runtime()
->pi_lock
rq->lock
scheduler_tick()
rq->lock
task_tick_fair()
update_curr()
account_group_exec()
cputimer->lock
Where the first one is enabling a CLOCK_PROCESS_CPUTIME_ID timer, and
the second one is keeping up-to-date.
This problem was introduced by e8abccb7193 ("posix-cpu-timers: Cure
SMP accounting oddities").
Cure the problem by removing the cputimer->lock and rq->lock nesting,
this leaves concurrent enablers doing duplicate work, but the time
wasted should be on the same order otherwise wasted spinning on the
lock and the greater-than assignment filter should ensure we preserve
monotonicity.
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Simon Kirby <sim@hostway.ca>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Link: http://lkml.kernel.org/r/1318928713.21167.4.camel@twins
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit a84a79e4d369a73c0130b5858199e949432da4c6 upstream.
The size is always valid, but variable-length arrays generate worse code
for no good reason (unless the function happens to be inlined and the
compiler sees the length for the simple constant it is).
Also, there seems to be some code generation problem on POWER, where
Henrik Bakken reports that register r28 can get corrupted under some
subtle circumstances (interrupt happening at the wrong time?). That all
indicates some seriously broken compiler issues, but since variable
length arrays are bad regardless, there's little point in trying to
chase it down.
"Just don't do that, then".
Reported-by: Henrik Grindal Bakken <henribak@cisco.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
irq_domain_generate_simple() is an easy way to generate an irq translation
domain for simple irq controllers. It assumes a flat 1:1 mapping from
hardware irq number to an offset of the first linux irq number assigned
to the controller
Change-Id: I0820754314a0c15b1cc9881bc38b75b0de2509b2
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Sathish Ambley <sambley@codeaurora.org>
This patch adds irq_domain infrastructure for translating from
hardware irq numbers to linux irqs. This is particularly important
for architectures adding device tree support because the current
implementation (excluding PowerPC and SPARC) cannot handle
translation for more than a single interrupt controller. irq_domain
supports device tree translation for any number of interrupt
controllers.
This patch converts x86, Microblaze, ARM and MIPS to use irq_domain
for device tree irq translation. x86 is untested beyond compiling it,
irq_domain is enabled for MIPS and Microblaze, but the old behaviour is
preserved until the core code is modified to actually register an
irq_domain yet. On ARM it works and is required for much of the new
ARM device tree board support.
PowerPC has /not/ been converted to use this new infrastructure. It
is still missing some features before it can replace the virq
infrastructure already in powerpc (see documentation on
irq_domain_map/unmap for details). Followup patches will add the
missing pieces and migrate PowerPC to use irq_domain.
SPARC has its own method of managing interrupts from the device tree
and is unaffected by this change.
Change-Id: Ia5fa674a97c85e2fc8e30275753b1494a97bd1d9
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Sathish Ambley <sambley@codeaurora.org>
The IRQS_PENDING flag is meant to record an edge interrupt trigger event
when that interrupt is disabled.
When an edge triggered interrupt is enabled, check_irq_resend() retriggers
that irq and resets the flag to zero if set. Note that check_irq_resend()
only does this for edge triggered interrupts.
For level triggered interrupts it is expected that the interrupt remains
active and doesn't need this PENDING flag assistance from software for
re-triggering it.
However, handle_fasteoi_irq flow handler sets the PENDING flag even for
a disabled level interrupt. This causes an adverse effect if that level
interrupt is marked wakeup. The suspend code sees the pending flag on a
wakeup interrupt and aborts suspend whereas check_irq_resend does not reset
it to 0 (as it is a level interrupt). The end result is that the PENDING
flag on this level triggered wakeup interrupt never clears and the system
keeps aborting suspend.
Fix this by setting IRQS_PENDING flag only for edge interrupts in the
handle_fasteoi_irq.
CRs-Fixed: 314344
Change-Id: I775d40f434f9309fd9672bae372b0f0fb5b91627
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
With this change, we do the average run queue statistics calculation
in the scheduler tick itself. This helps avoid any extra timers to
do the same. Also doing this calculation in the scheduler tick avoids
any bias if the calculation is done in a workqueue
Change-Id: I854d90acc05cc7a7226487be5555976826d8c837
Signed-off-by: Amar Singhal <asinghal@codeaurora.org>
commit f7bc8b61f65726ff98f52e286b28e294499d7a08 upstream.
Enabling function tracer to trace all functions, then load a module and
then disable function tracing will cause ftrace to fail.
This can also happen by enabling function tracing on the command line:
ftrace=function
and during boot up, modules are loaded, then you disable function tracing
with 'echo nop > current_tracer' you will trigger a bug in ftrace that
will shut itself down.
The reason is, the new ftrace code keeps ref counts of all ftrace_ops that
are registered for tracing. When one or more ftrace_ops are registered,
all the records that represent the functions that the ftrace_ops will
trace have a ref count incremented. If this ref count is not zero,
when the code modification runs, that function will be enabled for tracing.
If the ref count is zero, that function will be disabled from tracing.
To make sure the accounting was working, FTRACE_WARN_ON()s were added
to updating of the ref counts.
If the ref count hits its max (> 2^30 ftrace_ops added), or if
the ref count goes below zero, a FTRACE_WARN_ON() is triggered which
disables all modification of code.
Since it is common for ftrace_ops to trace all functions in the kernel,
instead of creating > 20,000 hash items for the ftrace_ops, the hash
count is just set to zero, and it represents that the ftrace_ops is
to trace all functions. This is where the issues arrise.
If you enable function tracing to trace all functions, and then add
a module, the modules function records do not get the ref count updated.
When the function tracer is disabled, all function records ref counts
are subtracted. Since the modules never had their ref counts incremented,
they go below zero and the FTRACE_WARN_ON() is triggered.
The solution to this is rather simple. When modules are loaded, and
their functions are added to the the ftrace pool, look to see if any
ftrace_ops are registered that trace all functions. And for those,
update the ref count for the module function records.
Reported-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
commit d670ec13178d0fd8680e6742a2bc6e04f28f87d8 upstream.
David reported:
Attached below is a watered-down version of rt/tst-cpuclock2.c from
GLIBC. Just build it with "gcc -o test test.c -lpthread -lrt" or
similar.
Run it several times, and you will see cases where the main thread
will measure a process clock difference before and after the nanosleep
which is smaller than the cpu-burner thread's individual thread clock
difference. This doesn't make any sense since the cpu-burner thread
is part of the top-level process's thread group.
I've reproduced this on both x86-64 and sparc64 (using both 32-bit and
64-bit binaries).
For example:
[davem@boricha build-x86_64-linux]$ ./test
process: before(0.001221967) after(0.498624371) diff(497402404)
thread: before(0.000081692) after(0.498316431) diff(498234739)
self: before(0.001223521) after(0.001240219) diff(16698)
[davem@boricha build-x86_64-linux]$
The diff of 'process' should always be >= the diff of 'thread'.
I make sure to wrap the 'thread' clock measurements the most tightly
around the nanosleep() call, and that the 'process' clock measurements
are the outer-most ones.
---
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <fcntl.h>
#include <string.h>
#include <errno.h>
#include <pthread.h>
static pthread_barrier_t barrier;
static void *chew_cpu(void *arg)
{
pthread_barrier_wait(&barrier);
while (1)
__asm__ __volatile__("" : : : "memory");
return NULL;
}
int main(void)
{
clockid_t process_clock, my_thread_clock, th_clock;
struct timespec process_before, process_after;
struct timespec me_before, me_after;
struct timespec th_before, th_after;
struct timespec sleeptime;
unsigned long diff;
pthread_t th;
int err;
err = clock_getcpuclockid(0, &process_clock);
if (err)
return 1;
err = pthread_getcpuclockid(pthread_self(), &my_thread_clock);
if (err)
return 1;
pthread_barrier_init(&barrier, NULL, 2);
err = pthread_create(&th, NULL, chew_cpu, NULL);
if (err)
return 1;
err = pthread_getcpuclockid(th, &th_clock);
if (err)
return 1;
pthread_barrier_wait(&barrier);
err = clock_gettime(process_clock, &process_before);
if (err)
return 1;
err = clock_gettime(my_thread_clock, &me_before);
if (err)
return 1;
err = clock_gettime(th_clock, &th_before);
if (err)
return 1;
sleeptime.tv_sec = 0;
sleeptime.tv_nsec = 500000000;
nanosleep(&sleeptime, NULL);
err = clock_gettime(th_clock, &th_after);
if (err)
return 1;
err = clock_gettime(my_thread_clock, &me_after);
if (err)
return 1;
err = clock_gettime(process_clock, &process_after);
if (err)
return 1;
diff = process_after.tv_nsec - process_before.tv_nsec;
printf("process: before(%lu.%.9lu) after(%lu.%.9lu) diff(%lu)\n",
process_before.tv_sec, process_before.tv_nsec,
process_after.tv_sec, process_after.tv_nsec, diff);
diff = th_after.tv_nsec - th_before.tv_nsec;
printf("thread: before(%lu.%.9lu) after(%lu.%.9lu) diff(%lu)\n",
th_before.tv_sec, th_before.tv_nsec,
th_after.tv_sec, th_after.tv_nsec, diff);
diff = me_after.tv_nsec - me_before.tv_nsec;
printf("self: before(%lu.%.9lu) after(%lu.%.9lu) diff(%lu)\n",
me_before.tv_sec, me_before.tv_nsec,
me_after.tv_sec, me_after.tv_nsec, diff);
return 0;
}
This is due to us using p->se.sum_exec_runtime in
thread_group_cputime() where we iterate the thread group and sum all
data. This does not take time since the last schedule operation (tick
or otherwise) into account. We can cure this by using
task_sched_runtime() at the cost of having to take locks.
This also means we can (and must) do away with
thread_group_sched_runtime() since the modified thread_group_cputime()
is now more accurate and would deadlock when called from
thread_group_sched_runtime().
Aside of that it makes the function safe on 32 bit systems. The old
code added t->se.sum_exec_runtime unprotected. sum_exec_runtime is a
64bit value and could be changed on another cpu at the same time.
Reported-by: David Miller <davem@davemloft.net>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1314874459.7945.22.camel@twins
Tested-by: David Miller <davem@davemloft.net>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 6ebbe7a07b3bc40b168d2afc569a6543c020d2e3 upstream.
Commit c259e01a1ec ("sched: Separate the scheduler entry for
preemption") contained a boo-boo wrecking wchan output. It forgot to
put the new schedule() function in the __sched section and thereby
doesn't get properly ignored for things like wchan.
Tested-by: Simon Kirby <sim@hostway.ca>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20110923000346.GA25425@hostway.ca
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 3be209a8e22cedafc1b6945608b7bb8d9887ab61 upstream.
Commit 43fa5460fe ("sched: Try not to
migrate higher priority RT tasks") also introduced a change in behavior
which keeps RT tasks on the same CPU if there is an equal priority RT
task currently running even if there are empty CPUs available.
This can cause unnecessary wakeup latencies, and can prevent the
scheduler from balancing all RT tasks across available CPUs.
This change causes an RT task to search for a new CPU if an equal
priority RT task is already running on wakeup. Lower priority tasks
will still have to wait on higher priority tasks, but the system should
still balance out because there is always the possibility that if there
are both a high and low priority RT tasks on a given CPU that the high
priority task could wakeup while the low priority task is running and
force it to search for a better runqueue.
Signed-off-by: Shawn Bohrer <sbohrer@rgmadvisors.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Tested-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1315837684-18733-1-git-send-email-sbohrer@rgmadvisors.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If there is a wakelock held the wakelock driver rejects the suspend
by returning EAGAIN(-11). In this case since the suspend is rejected
in suspend_noirq callback, the resume_noirq callback is not called on
the wakelock driver, leading to the check_done flag not being cleared
and causing a BUG for the next wakelock request.
Don't set the check_done flag if suspend_noirq aborts suspend.
Change-Id: Iddd12cefd9a30020784416b4e5bec7fe3f7fc0e6
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
This reverts commit ffdcd796e23c86d2cfeb25cb2d140f11d5fd6411.
This feature is replaced by passing 'earlyprintk' on the
kernel command line.
Change-Id: I2d4f2812e39b1c7afc061f106863b63710762fa7
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
When lazy disabling is implemented and an interrupt is disabled the
genirq code ends up marking it as IRQ_DISABLED in the descriptor.
The interrupt stays enabled in the controller. If the interrupt
fires after disabling, the flow handlers namely handle_level_irq and
handle_edge_irq mask the interrupt in the controller.
This is not the case with handle_nested_irq. The interrupt stays enabled in
the controller and if it were a level interrupt it keeps firing only to be
ignored by handle_nested_irq.
Update handle_nested_irq to mask such an interrupt.
CRs-Fixed: 300931
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Conflicts:
kernel/irq/chip.c
When IKCONFIG is built-in make oldconfig will cause the kernel to be
relinked even if .config didn't change. This happens because of a
config_data.gz dependency on .config. This patch changes the if_changed
to a filechk so that config_data.h is only rebuilt when the contents
have actually changed.
Change-Id: I0c907b5312e1059352a0afff688d8e015dec6bed
Signed-off-by: Peter Foley <pefoley2@verizon.net>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
