On 08/30/2012 01:26 PM, Rajendra Nayak wrote:
I tried 2012.07 (http://releases.linaro.org/12.07) ubuntu images and I get this
when I run perf :(
perf_3.4.0-2: error while loading shared libraries: libelf.so.1: cannot open
shared object file: No such file or directory
If your board connected
On 08/28/2012 10:58 AM, Rajendra Nayak wrote:
Does perf work fine on panda with the Linaro Ubuntu images?
Yes,it should work for 2012.07 Ubuntu images (except cross-replaying,
which works since 3.6.0-rc1).
Wanted to experiment with the tool a little, was wondering whats a good place to
start
On 08/15/2012 06:56 PM, Shubhrajyoti wrote:
How can I build perf myself?
I tried cross compiling but failed...:-(
what are the steps?
Cross-compiling is tricky because perf requires a lot of libraries.
I do it natively, using Ubuntu developer image. Also note that
perf can't be compiled outsid
On 08/15/2012 03:15 PM, Ramana Radhakrishnan wrote:
On 15 August 2012 09:23, Dmitry Antipov wrote:
Hello,
I'm running
https://android-build.linaro.org/builds/~linaro-android/panda-jb-gcc47-tilt-tracking-blob,
build 23 (Aug15). It's kernel version is 3.4.0-xxx, but 'perf --v
Hello Vishal,
is it possible to package the perf version matched to the kernel
version for our Android builds? Otherwise perf is just useless.
Dmitry
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lin
Hello,
I'm running
https://android-build.linaro.org/builds/~linaro-android/panda-jb-gcc47-tilt-tracking-blob,
build 23 (Aug15). It's kernel version is 3.4.0-xxx, but 'perf --version'
reports 3.0.8_android.
Why such a version mismatch? Usually it's the very poor idea to run perf on top
of misma
I remember that this was rejected some time ago. Nevertheless,
is it possible to accept this until we will have a better solution?
Dmitry
From 7b394670bee55ca694f921bd96f210b0d4c7dfe0 Mon Sep 17 00:00:00 2001
From: Dmitry Antipov
Date: Wed, 4 Jul 2012 13:20:59 +0400
Subject: [PATCH] perf sched
On 06/29/2012 05:12 PM, Ingo Molnar wrote:
Pulled, thanks Arnaldo!
As of ca24a145573124732152daff105ba68cc9a2b545, 'perf sched replay' is still
broken
(but 'perf report' works) if perf.data was recorded on another machine. For
example,
native replay is:
run measurement overhead: 0 nsecs
sle
On 06/26/2012 03:20 AM, Arnaldo Carvalho de Melo wrote:
Fair enough. The method should be a simple wrapper to libtraceevent APIs
like this patch.
The pevent thing is per perf.data file, so I made it stop being static
and become a perf_session member, so tools processing perf.data files
use pe
: Tue, 12 Jun 2012 14:05:13 -0300
From: Arnaldo Carvalho de Melo
To: Namhyung Kim , David Ahern ,
Jiri Olsa , Dmitry Antipov
Hi guys,
Could you please check out if my tmp.perf/core branch fixes the
problems reported lately about event name mismatches from perf.data
files collected in other
t, can we just lookup by name?
Dmitry
>From 5e1fbde04a2a8745711f439f4d4682b2215119b2 Mon Sep 17 00:00:00 2001
From: Dmitry Antipov
Date: Fri, 15 Jun 2012 11:49:47 +0400
Subject: [PATCH] perf: lookup by event name
Assuming event names are set, lookup tracepoint by name instead of ID.
Sign
Use new function trace_find_event_by_name to lookup events before
looking through /sys files. This helps 'perf sched replay' to map
event names to IDs correctly when processing perf.data recorded
on another machine.
Signed-off-by: Dmitry Antipov
---
tools/perf/util/evlist.c
Use trace_find_event to find event name before looking through
/sys files. This helps 'perf report' to show real event names
instead of 'unknown:unknown' when processing perf.data recorded
on another machine.
Signed-off-by: Dmitry Antipov
---
tools/perf/builtin-report.c
On 05/31/2012 11:04 PM, Pantelis Antoniou wrote:
Please do a perf sched spr-replay -l -n -d -d and send me the output.
There was a change made to the way names are recorded, and this could have
affected it.
Attached. You can also grab perf.data at http://78.153.153.8/tmp/perf.data.gz
and see w
On 05/31/2012 11:41 AM, Pantelis Antoniou wrote:
There are a number of problems that this patch solves.
Do you have a feedback from core perf developers?
1. The format used by default is the binary perf trace format which is
both non-portable between arches and non human editable. The format
On 05/29/2012 07:10 PM, Arnaldo Carvalho de Melo wrote:
I haven't tested this, but libtraceevent is now in, perhaps it works for
you now? Can you check?
It doesn't work. Attempt to do 'perf report' on ARM for the data collected on
x86 shows 'unknown:unknown' for event names (see report_x86_on_
On 05/17/2012 03:48 PM, Steven Rostedt wrote:
trace-cmd copies the entire /sys/kernel/debug/tracing/events directory
into the data file (well it copies only the events you specify).
I thought perf did the same. It should be using what's in the perf.dat
file and not what's on the host.
I found
Hello all,
I'm interesting in obtaining perf.data files recorded on a different ARM boards.
For those who has no ideas about what is it, you may take a quick look at
https://perf.wiki.kernel.org/index.php/Main_Page. If you're able to use
apt-get or other ways to install a few packages on your boa
On 05/16/2012 08:58 PM, Steven Rostedt wrote:
On Wed, 2012-05-16 at 11:59 -0300, Arnaldo Carvalho de Melo wrote:
Steve,
Was the kernel trace events infrastructure designed with that in
mind? I.e. cross analysis? I must be missing something here, still
ENOCOFFEE :-\
Yes, the libparse
On 05/15/2012 07:51 PM, Arnaldo Carvalho de Melo wrote:
Em Tue, May 15, 2012 at 07:27:39PM +0400, Dmitry Antipov escreveu:
Hello,
are there any thoughts on how much of the perf.data is portable and how much it
should be?
I'm interesting in recording scheduler activity on one machine and
Hello,
are there any thoughts on how much of the perf.data is portable and how much it
should be?
I'm interesting in recording scheduler activity on one machine and then
replaying on
another. As I can see, replaying x86 perf.data on ARM doesn't work. At least,
should it
work with a small subse
On 04/12/2012 04:51 PM, Pantelis Antoniou wrote:
The data file is not readable by me version of perf.
Oops. This should be investigated. We definitely wants the perf
data to be portable (or, at least, portable with some limitations
between different hardware of the same major architecture).
C
On 04/09/2012 09:24 PM, Pantelis Antoniou wrote:
Here's a updated patch for builtin-sched.c that should fix your issues.
Now when you issue list a field will show the amount of nsecs the
task was burning cycles.
It should also fix the crash you've encountered.
1) IIUC, 'perf sched spr-replay
On 04/09/2012 09:24 PM, Pantelis Antoniou wrote:
Here's a updated patch for builtin-sched.c that should fix your issues.
Now when you issue list a field will show the amount of nsecs the
task was burning cycles.
It should also fix the crash you've encountered.
Thanks, I'm trying it now.
BTW
On 04/04/2012 05:10 PM, Pantelis Antoniou wrote:
The reason for the slowdown is that perf sched record default settings is
tuned for x86 pretty much, and there's a huge amount of data being generated.
perf sched record is just a wrapper for perf record so try using this script
for recording:
On 04/05/2012 04:10 AM, Andrew Morton wrote:
Well.. there are some back-incompatibilities here.
prctl(PR_SET_TIMERSLACK, -1) used to restore current's slack setting to
whatever-we-inherited-at-fork, but that has been removed. What are the
implications of this, and did we need to do it?
It se
Document PR_GET_TIMERSLACK and PR_SET_TIMERSLACK for prctl (2).
Document /proc/sys/kernel/timer_slack for proc (5).
Signed-off-by: Dmitry Antipov
---
man2/prctl.2 | 15 +++
man5/proc.5 |4
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/man2/prctl.2 b
On 04/02/2012 02:18 PM, Pantelis Antoniou wrote:
Ah, about the load it's because perf sched record adds too many events to the
recording (and configuring small buffers for perf). Using a smaller set
of events works much better.
I tried with a different subsets of 'sched:*' events, but it didn'
On 04/02/2012 02:15 PM, Pantelis Antoniou wrote:
Example session:
# perf sched record
< run process, etc.>
^C<- perf ends producing a perf.data file.
# perf sched spr-replay -l
# perf sched spr-replay -s -s -d -n -g
# perf sched spr-replay -s -g>test.spr
# perf sched spr-replay -f
On 03/08/2012 05:20 PM, Pantelis Antoniou wrote:
The current issue is that scheduler development is not easily shared between
developers. Each developer has their own 'itch', be it Android use cases, server
workloads, VM, etc. The risk is high of optimizing for one's own use case and
causing sev
On 02/28/2012 05:27 PM, Ming Lei wrote:
I am sure that several guys have tried the current omap4 pmu patch
and make perf work well on pandaboard.
On a freshly booted panda board which is mostly idle:
root@linaro-developer:~# uptime
14:44:36 up 1 min, 3 users, load average: 0.17, 0.11, 0.05
Are there any efforts going on LatencyTOP? Is it dead?
Is it canceled in favor of another similar project?
Dmitry
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
NULL, "func");
return IS_ERR(tsk) ? PTR_ERR(tsk) : 0;
}
static void __exit modexit(void)
{
wait_for_completion(&done);
}
Reviewed-by: Andrew Morton
Signed-off-by: Dmitry Antipov
---
include/linux/kthread.h |3 ++
kernel/kthre
On 02/29/2012 12:43 AM, Andrew Morton wrote:
Please make the stub function a proper C function, not a macro. It
provides type checking, can prevent compile warnings and is generally
easier on the eyes.
OK
I think this should be under the kernel hacking menu, dependent on
CONFIG_DEBUG_KERNEL
On 02/28/2012 05:30 PM, Dan Carpenter wrote:
Could you include that in the changelog when the final version is
ready?
What changelog you're saying about?
Dmitry
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman
On 02/28/2012 05:27 PM, Ming Lei wrote:
OK, could you try the MLO and u-boot.bin under the link of
http://kernel.ubuntu.com/~ming/up to see if 'perf' may work well?
Is it really possible that the bootloader stuff affects perf/oprofile?
If still not, could you tell me what is the revision of
On 02/28/2012 04:45 AM, Ming Lei wrote:
Please try the uImage on the link below:
http://kernel.ubuntu.com/~ming/up/uImage-3.3-rc5-perf
No good news for the oprofile:
...
irq 34: nobody cared (try booting with the "irqpoll" option)
[stack]
Disabling IRQ #34
irq 33: nobody cared (try b
On 02/28/2012 01:44 PM, Dan Carpenter wrote:
On Tue, Feb 28, 2012 at 01:33:59PM +0400, Dmitry Antipov wrote:
- Fix vmap() to return ZERO_SIZE_PTR if 0 pages are requested;
- fix __vmalloc_node_range() to return ZERO_SIZE_PTR if 0 bytes
are requested;
- fix __vunmap() to check passed
Use ZERO_OR_NULL_PTR allocation pointer checking where allocation
function may return ZERO_SIZE_PTR.
---
kernel/module.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index 2c93276..ae438db 100644
--- a/kernel/module.c
+++ b/kerne
- Fix vmap() to return ZERO_SIZE_PTR if 0 pages are requested;
- fix __vmalloc_node_range() to return ZERO_SIZE_PTR if 0 bytes
are requested;
- fix __vunmap() to check passed pointer with ZERO_OR_NULL_PTR.
Signed-off-by: Dmitry Antipov
---
mm/vmalloc.c | 10 +++---
1 files changed
NULL, "func");
return IS_ERR(tsk) ? PTR_ERR(tsk) : 0;
}
static void __exit modexit(void)
{
wait_for_completion(&done);
}
Signed-off-by: Dmitry Antipov
---
include/linux/kthread.h |5 +
init/Kconfig|9 +
kernel/kthre
task uses system-wide value by
default, and newborn thread uses it's group leader value.
Signed-off-by: Dmitry Antipov
---
Documentation/sysctl/kernel.txt |8
include/linux/hrtimer.h | 11 +++
include/linux/init_task.h |2 +-
include/linux/sched.h
Suggested-by: Ingo Molnar
Suggested-by: Peter Zijlstra
Acked-by: Venkatesh Pallipadi
Signed-off-by: Dmitry Antipov
---
Documentation/kernel-parameters.txt |9 +
arch/arm/kernel/sched_clock.c |2 ++
arch/x86/Kconfig| 11 ---
arch/x86/kernel/tsc.c
On 02/27/2012 02:12 PM, Peter Zijlstra wrote:
-extern void enable_sched_clock_irqtime(void);
-extern void disable_sched_clock_irqtime(void);
+extern int sched_clock_irqtime;
+static inline void enable_sched_clock_irqtime(void)
+{
+ if (sched_clock_irqtime == -1)
+ sched_clock
On 02/27/2012 06:27 PM, Ming Lei wrote:
After some check, I just found there is another patch you missed.
Please try the attachment patch from Shilimkar, Santosh.
If it doesn't work, I can send my uImage for your test.
No effect, so please send an uImage if possible.
I'm re-sending cumulativ
On 02/25/2012 07:24 AM, Ming Lei wrote:
BTW: suggest you to apply the recent arm pmu irq fix patches[1] to
test 'oprofile'.
[1], http://marc.info/?t=13300128495&r=1&w=2
I tried, and with the same results - "nobody cared" messages
about IRQs 33 and 34.
Dmitry
___
On 02/23/2012 04:57 AM, Ming Lei wrote:
No, it doesn't work with upstream kernel now. You need to apply the
patches[1][2]
against upstream kernel to route CTIs IRQ so that OMAP4 PMU/perf can work well.
[1], http://marc.info/?l=linux-omap&m=132686049213313&w=2
[2], http://marc.info/?l=linux-arm-
On 02/22/2012 05:59 PM, Dave Martin wrote:
However, the way that the performance counter interrupts are routed is
dependent on the SoC. OMAP4 and later have an unusual way of doing this,
which is why perf doesn't currently work upstream for these platforms.
But will it work on Panda board wit
On 02/22/2012 02:57 PM, Ming Lei wrote:
I didn't use oprofile before and always use 'perf', and I am sure
it works well with arm a9 pmu hardware on linus tree.
Should we consider oprofile as obsolete in favor of perf?
Are these projects competing to be a default system profiling
tool for Linu
Hello Ming,
could you please give some pointers to observe an overall status of
oprofile support on ARM A9 cores? IIUC, now it doesn't work
without oprofile.timer=1 kernel option, at least for Linus' tree;
searching gives a lot of discussion/patches fragments and similar
stuff, but I was unable t
task uses system-wide value by
default, and newborn thread uses it's group leader value.
Signed-off-by: Dmitry Antipov
---
Documentation/sysctl/kernel.txt |8
include/linux/hrtimer.h | 11 +++
include/linux/init_task.h |2 +-
include/linux/sched.h
Suggested-by: Ingo Molnar
Acked-by: Venkatesh Pallipadi
Signed-off-by: Dmitry Antipov
---
Documentation/kernel-parameters.txt |9 +
arch/arm/kernel/sched_clock.c |2 ++
arch/x86/Kconfig| 11 ---
arch/x86/kernel/tsc.c | 12 ++-
On 02/14/2012 04:43 PM, Andrey Konovalov wrote:
Your fix seems ok for ubuntu/debian, but this would not work in general case.
E.g. Fedora doesn't have /usr/bin/pager.
So this doesn't look like a generic solution that fits into linux-linaro kernel.
I believe pager = "/bin/more" is more portable
Acked-by: Venkatesh Pallipadi
Signed-off-by: Dmitry Antipov
---
Documentation/kernel-parameters.txt |9 +
arch/arm/kernel/sched_clock.c |2 ++
arch/x86/Kconfig| 11 ---
arch/x86/kernel/tsc.c | 12 ++--
include/linux/sched.h
On 02/09/2012 10:40 AM, Richard Cochran wrote:
I thought this list was about Linux kernel development, but now it
seems to be about Sun's old bugs.
This Sun (probably) has ~10x more accurate hrtimers than it's said,
and it's a bug. My panda board (with 32K timer enabled) has ~3x
less a
Suggested-by: Venki Pallipadi
Signed-off-by: Dmitry Antipov
---
Documentation/kernel-parameters.txt |9 +
arch/arm/kernel/sched_clock.c |2 ++
arch/x86/Kconfig| 11 ---
arch/x86/kernel/tsc.c | 12 ++--
include/linux/sched.h
On 02/09/2012 02:12 AM, Thomas Gleixner wrote:
It would be possible to return the real resolution of the clock event
device, but we have systems, where the clockevent device is
dynamically changing. So which resolution do we expose to an
application? The one of the current active device or some
On 02/08/2012 09:12 PM, Richard Cochran wrote:
I think "resolution" does not mean tick duration, but rather the finest timer
unit.
#include
#include
int main (int argc, char *argv[])
{
int i;
struct timespec rs, ts[10];
clock_getres (CLOCK_REALTIME, &rs);
printf ("res: %lus %luns\
ipadi
Signed-off-by: Dmitry Antipov
---
Documentation/kernel-parameters.txt |9 +
arch/arm/kernel/sched_clock.c |3 +++
arch/x86/Kconfig| 11 ---
arch/x86/kernel/tsc.c |7 ---
include/linux/sched.h |2 +
Are there up-to-date instructions on how to bring up oprofile on panda board?
I tried a lot of things found in oprofile manual and google results, but the
only thing I have is:
$ opreport
error: no sample files found: profile specification too strict ?
Dmitry
___
IIUC, an idea behind clock_getres() is to give a hint about the resolution of
specified clock. This hint may be used by an application programmer to check
whether
this clock is suitable for a some purpose. So why clock_getres() always returns
something like {0, 1} (if hrtimers are enabled) regard
ipadi
Signed-off-by: Dmitry Antipov
---
arch/arm/kernel/sched_clock.c |3 +++
arch/x86/Kconfig | 11 ---
arch/x86/kernel/tsc.c |7 ---
include/linux/sched.h |2 ++
lib/Kconfig.debug | 12
lib/Makefile
On 02/08/2012 05:18 AM, Russell King - ARM Linux wrote:
diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index 5416c7c..56d2a9d 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -162,5 +162,8 @@ void __init sched_clock_postinit(void)
On 02/08/2012 01:32 AM, Andrew Richardson wrote:
Do you recommend using "Get linaro image tools: method 2 (source code)"
( http://releases.linaro.org/12.01/ubuntu/leb-panda/ ) and building the
kernel myself?
Unfortunately this is the only way. In theory, there are clocksource=
boot option, and
Generalize CONFIG_IRQ_TIME_ACCOUNTING between X86 and
ARM, move "noirqtime=" option to common debugging code.
For a bit of backward compatibility, "tsc=noirqtime"
is preserved, but issues a warning.
Suggested-by: Venki Pallipadi
Signed-off-by: Dmitry Antipov
---
arch/arm/
On 02/07/2012 02:43 PM, Andrew Richardson wrote:
I'm experiencing what appears to be a minimum clock resolution issue
in using clock_gettime() on a PandaBoard ES running ubuntu.
Do you have CONFIG_OMAP_32K_TIMER enabled in your kernel?
Look at 'dmesg | grep clock' and check for the following:
Generalize CONFIG_IRQ_TIME_ACCOUNTING between X86 and
ARM, move "noirqtime=" option to common debugging code.
Signed-off-by: Dmitry Antipov
---
arch/arm/kernel/sched_clock.c |3 +++
arch/x86/Kconfig | 11 ---
arch/x86/kernel/tsc.c |4
inc
k
why it might be useful.
Signed-off-by: Dmitry Antipov
---
include/linux/kthread.h |5 +
init/Kconfig|9 +
kernel/kthread.c| 24
kernel/module.c | 45 +
4 files changed, 83 in
On 02/01/2012 04:15 PM, Daniel Lezcano wrote:
Yes, but the problem is the same also. Did you try
by removing atomic_inc and set nrunnings to nrkthread ?
Unfortunately it's still here:
Unable to handle kernel paging request at virtual address 7f0a411c
pgd = 80004000
[7f0a411c] *pgd=bf163811, *
On 02/01/2012 04:15 PM, Daniel Lezcano wrote:
Yes, but the problem is the same also. Did you try by removing atomic_inc and
set nrunnings to nrkthread ?
Now I'm trying, and it looks better - but hurts the lockdep validator :-(:
BUG: MAX_LOCKDEP_KEYS too low!
turning off the locking correctne
On 02/01/2012 03:49 PM, Daniel Lezcano wrote:
IMO, you have a race condition with nrunning. What guarantee do you
have atomic_dec_and_test is called after atomic_inc ?
Nothing (but I believe ~1s is pretty enough for the kernel thread to get
woken up). I also tried to to atomic_inc() at the beg
I'm writing a kernel module which creates a substantial amount of
kernel threads. After dropping the real stuff, the module skeleton is:
#include
#include
#include
#include
#include
#include
MODULE_LICENSE("GPL");
static int nrthreads = 128;
module_param(nrthreads, int, 0644);
static int
Since CONFIG_IRQ_TIME_ACCOUNTING is architecture-agnostic,
move it from x86 area to common code.
Signed-off-by: Dmitry Antipov
---
arch/x86/Kconfig | 11 ---
lib/Kconfig.debug | 11 +++
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/x86/Kconfig b/arch
Use ZERO_OR_NULL_PTR allocation pointer checking where allocation
function may return ZERO_SIZE_PTR.
Signed-off-by: Dmitry Antipov
---
kernel/module.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index 2c93276..5183f91
- Fix vmap() to return ZERO_SIZE_PTR if 0 pages are requested;
- fix __vmalloc_node_range() to return ZERO_SIZE_PTR if 0 bytes
are requested;
- fix __vunmap() to check passed pointer with ZERO_OR_NULL_PTR.
Signed-off-by: Dmitry Antipov
---
mm/vmalloc.c | 10 +++---
1 files changed
Fix pcpu_alloc() to return ZERO_SIZE_PTR if requested size is 0;
fix free_percpu() to check passed pointer with ZERO_OR_NULL_PTR.
Signed-off-by: Dmitry Antipov
---
mm/percpu.c | 16 +++-
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/mm/percpu.c b/mm/percpu.c
On 01/27/2012 03:21 PM, Rusty Russell wrote:
Please fix __vmalloc_node_range() instead to return ZERO_SIZE_PTR.
And of course, vfree() to use ZERO_OR_NULL_PTR().
For the convenience and uniformity, should {alloc,free}_percpu() be
also modified in that way?
Dmitry
.
Signed-off-by: Dmitry Antipov
---
include/linux/hrtimer.h |1 +
include/linux/sched.h | 11 ---
kernel/fork.c |3 ---
kernel/futex.c |4 ++--
kernel/hrtimer.c| 10 +++---
kernel/sys.c|3 ++-
kernel/sysctl.c | 10
For the architectures with it's own module_alloc(), if module init
size is zero, avoiding module_alloc_update_bounds() and memset()
no-op calls also eliminates warn_alloc_failed() zero-size warning
in __vmalloc_node_range().
Signed-off-by: Dmitry Antipov
---
kernel/module.c |
On 01/25/2012 04:01 AM, john stultz wrote:
Why do you want to move loops like the above from jiffies based timeouts
to hrtimers?
I'm trying to see whether there are possible benefits in the sense of power
management.
More hrtimers with larger expire deltas -> more opportunities to coalesce
h
()) {
if (timeout > USEC_PER_SEC)
return -ETIMEDOUT;
timeout += usleep_range(500, 1500);
}
Signed-off-by: Dmitry Antipov
---
fs/eventpoll.c |3 ++-
fs/select.c |3 ++-
include/linux/delay.h |3 ++-
include/linux/hrtimer.h |
Use usleep_range() with return value to implement time-bounded
wait-for hardware loop where delay is applicable; use ktime
instead of jiffies for a busy-wait loop.
Signed-off-by: Dmitry Antipov
---
drivers/net/usb/smsc95xx.c | 52 ---
1 files changed
Use usleep_range() with return value to implement time-bounded
wait-for hardware loop where delay is applicable; use ktime
instead of jiffies for a busy-wait loop.
Signed-off-by: Dmitry Antipov
---
drivers/i2c/busses/i2c-omap.c | 23 +++
1 files changed, 11 insertions
Teach usleep_range() to return how many usecs was actually spent in
sleep. The rationale beyond this is to convert jiffies-based time-bound
wait-for-hardware loops from using msleep() to usleep_range().
Signed-off-by: Dmitry Antipov
---
fs/eventpoll.c |2 +-
fs/select.c
On 01/13/2012 05:22 PM, Aaro Koskinen wrote:
Anyway, I think the change is good. On systems with multiple MMC devices
the boot/probe can spend 100-200 ms alone just doing busylooping delays. I
think e.g. in mmc_rescan() the code uses frequently mmc_delay(10).
I'm worrying about this:
mmc_dela
On 12/21/2011 03:25 PM, Sujit Reddy Thumma wrote:
I have posted similar patch some time back.
http://comments.gmane.org/gmane.linux.ports.arm.msm/2119.
Would you like to comment on that?
- I believe we should forget about jiffies, HZ and other similar obsolete
timekeeping stuff;
- I have n
From ac60fe289eef3d81009f2b14a12acbac3e71878b Mon Sep 17 00:00:00 2001
From: Dmitry Antipov
Date: Wed, 21 Dec 2011 11:05:27 +0400
Subject: [PATCH] ohci-hcd: use usleep_range() instead of mdelay()
---
drivers/usb/host/ohci-hcd.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions
From 00753f3d48c4b6c45c1778c3e37bc9949ed79e77 Mon Sep 17 00:00:00 2001
From: Dmitry Antipov
Date: Wed, 21 Dec 2011 11:01:42 +0400
Subject: [PATCH] regulator: use usleep_range() instead of mdelay()/udelay()
---
drivers/regulator/core.c |7 +--
1 files changed, 1 insertions(+), 6
From e4db974edb5c46360465462518a88b83f1bdedf6 Mon Sep 17 00:00:00 2001
From: Dmitry Antipov
Date: Wed, 21 Dec 2011 10:57:08 +0400
Subject: [PATCH] omap: use usleep_range() instead of mdelay()/udelay()
---
arch/arm/mach-omap2/omap_phy_internal.c |2 +-
arch/arm/mach-omap2/vc.c
From f447d78db65c6675e69466e8ed08364ff065ac08 Mon Sep 17 00:00:00 2001
From: Dmitry Antipov
Date: Wed, 21 Dec 2011 10:51:03 +0400
Subject: [PATCH] mmc: use usleep_range() in mmc_delay()
---
drivers/mmc/core/core.h |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a
90 matches
Mail list logo
