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: <1336516020.8226.57.camel@twins>
Date:	Wed, 09 May 2012 00:27:00 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
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 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.

--
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/