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]

Message-ID: <1336516174.8226.59.camel@twins>
Date:	Wed, 09 May 2012 00:29:34 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Diwakar Tundlam <dtundlam@...dia.com>
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

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/