| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <1DD7BFEDD3147247B1355BEFEFE46652379C3DF10E@HQMAIL04.nvidia.com>
Date: Tue, 8 May 2012 15:46:54 -0700
From: Diwakar Tundlam <dtundlam@...dia.com>
To: 'Peter Zijlstra' <peterz@...radead.org>
CC: 'Ingo Molnar' <mingo@...nel.org>,
'David Rientjes' <rientjes@...gle.com>,
"'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>,
Peter De Schrijver <pdeschrijver@...dia.com>
Subject: RE: [PATCH] sched: Make nr_uninterruptible count a signed value
> No that's right. nr_uninterruptible counts the number of tasks in
> uninterruptible sleep, so deactivate_task puts a task to sleep, so we
> need to increment the number of sleeping tasks, activate_task wakes a
> task up so we need to decrement the number of sleeping tasks.
Yep, I looked at the code for task_contributes_to_load() and I understand what it is all about.
The ++ and -- are correct, I see it now.
On the -ve values, strangely inspite of %Ld in the print statement, in my kernel, I see high unsigned values instead of -ve values for nr_uninterruptible.
But the sum is always 0, though.
Maybe it is an artifact of 32-bit machine displaying 64-bit print format.
An (unsigned long)(-24) promoted to (signed long long) ends up as 4294967272.
As seen in my output of sched_debug.
Your machine is probably natively 64-bit.
$ adb shell cat /proc/sched_debug |egrep 'cpu#|nr_'
cpu#0
.nr_running : 1
.nr_switches : 16233
.nr_load_updates : 2529
.nr_uninterruptible : 4294967272 <<<<< 0xffffffe8 == (-24)
.nr_spread_over : 18
.nr_running : 0
.nr_spread_over : 101
.nr_running : 1
.rt_nr_running : 0
.rt_nr_running : 0
.rt_nr_running : 0
cpu#1
.nr_running : 1
.nr_switches : 7891
.nr_load_updates : 2124
.nr_uninterruptible : 18
.nr_spread_over : 121
.nr_running : 1
.rt_nr_running : 0
.rt_nr_running : 0
.rt_nr_running : 0
cpu#3
.nr_running : 1
.nr_switches : 13896
.nr_load_updates : 1179
.nr_uninterruptible : 6
.nr_spread_over : 106
.nr_running : 1
.rt_nr_running : 0
.rt_nr_running : 0
.rt_nr_running : 0
Thanks,
--Diwakar.
-----Original Message-----
From: Peter Zijlstra [mailto:peterz@...radead.org]
Sent: Tuesday, May 08, 2012 3:30 PM
To: Diwakar Tundlam
Cc: 'Ingo Molnar'; 'David Rientjes'; 'linux-kernel@...r.kernel.org'; Peter De Schrijver
Subject: RE: [PATCH] sched: Make nr_uninterruptible count a signed value
On Wed, 2012-05-09 at 00:27 +0200, Peter Zijlstra wrote:
> On Tue, 2012-05-08 at 15:14 -0700, Diwakar Tundlam wrote:
> > Sorry to bug you when it is late for you..
> >
> Nah, I'm the idiot still behind the screen after midnight, its just
> the brain that's slightly slower and needs more hints.
>
> > You're right, there is no real difference at all.
> > Only cosmetic difference when you look at the output of cat
> > /proc/sched_debug.
>
> Not sure I see that.. the printf is still using %Ld (signed) so the
> output shouldn't matter regardless of if the variable is unsigned long
> or long.
> >
> > But I suddenly realized maybe the increment/decrement of
> > nr_interruptible is reversed.
> > Maybe that's the source of the problem: decrement in activate task
> > and increment in deactivate task !!
>
> No that's right. nr_uninterruptible counts the number of tasks in
> uninterruptible sleep, so deactivate_task puts a task to sleep, so we
> need to increment the number of sleeping tasks, activate_task wakes a
> task up so we need to decrement the number of sleeping tasks.
>
> I think the problem you're having is that we don't match the cpu where
> we inc and dec the counter, and that's fully on purpose since its
> rather expensive -- it would require atomics.
>
FWIW the way to properly read the sched_debug output is something like:
# grep nr_uninterruptible /proc/sched_debug
.nr_uninterruptible : -1305
.nr_uninterruptible : 336
.nr_uninterruptible : -229
.nr_uninterruptible : 276
.nr_uninterruptible : 105
.nr_uninterruptible : 157
.nr_uninterruptible : -2782
.nr_uninterruptible : 325
.nr_uninterruptible : -471
.nr_uninterruptible : 9
.nr_uninterruptible : 205
.nr_uninterruptible : 88
.nr_uninterruptible : 7
.nr_uninterruptible : 912
.nr_uninterruptible : 188
.nr_uninterruptible : 66
.nr_uninterruptible : 87
.nr_uninterruptible : 45
.nr_uninterruptible : 194
.nr_uninterruptible : 1178
.nr_uninterruptible : 185
.nr_uninterruptible : 143
.nr_uninterruptible : 136
.nr_uninterruptible : 145
# awk '/nr_uninterruptible/ {t += $3} END {print t}' /proc/sched_debug
0
The per-cpu value is meaningless, only the sum over all cpus is a meaningful number.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists