linux-kernel - RE: [PATCH] sched: Make nr_uninterruptible count a signed value

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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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/