KOSAKI Motohiro wrote:
Hi
+static void __sched
+account_global_scheduler_latency(struct task_struct *tsk, int usecs)
+{
+ int i;
+ int firstnonnull = MAXLR + 1;
+
+ if (!tsk->latency_reason.reason)
+ return;
+
+ /* skip kernel threads for now */
+ if
Hi
> +static void __sched
> +account_global_scheduler_latency(struct task_struct *tsk, int usecs)
> +{
> + int i;
> + int firstnonnull = MAXLR + 1;
> +
> + if (!tsk->latency_reason.reason)
> + return;
> +
> + /* skip kernel threads for now */
> + if (!tsk->mm)
> +
Hi
+static void __sched
+account_global_scheduler_latency(struct task_struct *tsk, int usecs)
+{
+ int i;
+ int firstnonnull = MAXLR + 1;
+
+ if (!tsk-latency_reason.reason)
+ return;
+
+ /* skip kernel threads for now */
+ if (!tsk-mm)
+
KOSAKI Motohiro wrote:
Hi
+static void __sched
+account_global_scheduler_latency(struct task_struct *tsk, int usecs)
+{
+ int i;
+ int firstnonnull = MAXLR + 1;
+
+ if (!tsk-latency_reason.reason)
+ return;
+
+ /* skip kernel threads for now */
+ if
On 20/01/2008, Dmitry Adamushko <[EMAIL PROTECTED]> wrote:
> Hello Arjan,
>
> a few comments on the current locking scheme.
heh... now having read the first message in this series ("[Announce]
Development release 0.1 of the LatencyTOP tool"), I finally see that
"fine-grained locking" is still on
Hello Arjan,
a few comments on the current locking scheme.
There is a single global lock and the locked section in
account_scheduler_latency() seems to be quite long:
(at worst case)
- get_wchan() ;
- account_global_scheduler_latency() which does up to MAXLR (128)
loops x2 strcmp() operations;
Arjan van de Ven wrote:
> [linux-2.6.24-rc7/include/linux/latencytop.h]
> +struct latency_entry {
> + char*reason;
>...
> +struct latency_record {
> + char*reason;
>...
> +struct latency_entry *set_latency_reason(char *reason,
>...
I'd propose to mark the "reason" entries above
Arjan van de Ven wrote:
[linux-2.6.24-rc7/include/linux/latencytop.h]
+struct latency_entry {
+ char*reason;
...
+struct latency_record {
+ char*reason;
...
+struct latency_entry *set_latency_reason(char *reason,
...
I'd propose to mark the reason entries above (and the
Hello Arjan,
a few comments on the current locking scheme.
There is a single global lock and the locked section in
account_scheduler_latency() seems to be quite long:
(at worst case)
- get_wchan() ;
- account_global_scheduler_latency() which does up to MAXLR (128)
loops x2 strcmp() operations;
On 20/01/2008, Dmitry Adamushko [EMAIL PROTECTED] wrote:
Hello Arjan,
a few comments on the current locking scheme.
heh... now having read the first message in this series ([Announce]
Development release 0.1 of the LatencyTOP tool), I finally see that
fine-grained locking is still on your todo
This patch is the core LatencyTOP kernel infrastructure;
it measures latencies in the scheduler and tracks it system
wide and per process
---
fs/proc/base.c | 61 +
include/linux/latencytop.h | 62 +
include/linux/sched.h |6
kernel/Makefile|
This patch is the core LatencyTOP kernel infrastructure;
it measures latencies in the scheduler and tracks it system
wide and per process
---
fs/proc/base.c | 61 +
include/linux/latencytop.h | 62 +
include/linux/sched.h |6
kernel/Makefile|
12 matches
Mail list logo
