All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Diwakar Tundlam <dtundlam@nvidia.com>
Cc: "'Ingo Molnar'" <mingo@kernel.org>,
	"'David Rientjes'" <rientjes@google.com>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>,
	Peter De Schrijver <pdeschrijver@nvidia.com>
Subject: RE: [PATCH] sched: Make nr_uninterruptible count a signed value
Date: Wed, 09 May 2012 00:27:00 +0200	[thread overview]
Message-ID: <1336516020.8226.57.camel@twins> (raw)
In-Reply-To: <1DD7BFEDD3147247B1355BEFEFE46652379C3DF10D@HQMAIL04.nvidia.com>

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.


  reply	other threads:[~2012-05-08 22:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-08 21:39 [PATCH] sched: Make nr_uninterruptible count a signed value Diwakar Tundlam
2012-05-08 21:56 ` Peter Zijlstra
2012-05-08 22:14   ` Diwakar Tundlam
2012-05-08 22:27     ` Peter Zijlstra [this message]
2012-05-08 22:29       ` Peter Zijlstra
2012-05-08 22:46         ` Diwakar Tundlam
2012-05-09  7:49           ` Michael Wang
2012-05-09 18:55             ` Diwakar Tundlam
2012-05-10  4:46               ` Michael Wang
2012-05-09  8:11           ` Peter Zijlstra
2012-05-09 19:04             ` Diwakar Tundlam
2012-05-10  3:41             ` Michael Wang
2012-05-10  9:46               ` Peter Zijlstra
2012-05-11  2:19                 ` Michael Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1336516020.8226.57.camel@twins \
    --to=a.p.zijlstra@chello.nl \
    --cc=dtundlam@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=pdeschrijver@nvidia.com \
    --cc=rientjes@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.