All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Andrea Righi <andrea@betterlinux.com>
Cc: Paul Menage <paul@paulmenage.org>, Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, Paul Turner <pjt@google.com>,
	Glauber Costa <glommer@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH RFC 1/3] sched: introduce distinct per-cpu load average
Date: Thu, 04 Oct 2012 14:12:08 +0200	[thread overview]
Message-ID: <1349352728.4438.23.camel@twins> (raw)
In-Reply-To: <20121004094349.GA2163@thinkpad>

On Thu, 2012-10-04 at 11:43 +0200, Andrea Righi wrote:
> 
> Right, the update must be atomic to have a coherent nr_uninterruptible
> value. And AFAICS the only way to account a coherent
> nr_uninterruptible
> value per-cpu is to go with atomic ops... mmh... I'll think more on
> this. 

You could stick it in the cpu controller instead of cpuset, add a
per-cpu nr_uninterruptible counter to struct task_group and update it
from the enqueue/dequeue paths. Those already are per-cgroup (through
cfs_rq, which has a tg pointer).

That would also give you better semantics since it would really be the
load of the tasks of the cgroup, not whatever happened to run on a
particular cpu regardless of groups. Then again, it might be 'fun' to
get the hierarchical semantics right :-)

OTOH it would also make calculating the load-avg O(nr_cgroups) and since
we do this from the tick and people are known to create a shitload (on
the order of 1e3 and upwards) of those this might not actually be a very
good idea.

Also, your patch 2 relies on the load avg function to be additive yet
your completely fail to mention this and state whether this is so or
not.

Furthermore, please look at PER_CPU() and friends as alternatives to
[NR_CPUS] arrays.

  reply	other threads:[~2012-10-04 12:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-03 23:05 [PATCH RFC 0/3] per cpuset load average Andrea Righi
2012-10-03 23:05 ` [PATCH RFC 1/3] sched: introduce distinct per-cpu " Andrea Righi
2012-10-04  8:59   ` Peter Zijlstra
2012-10-04  9:43     ` Andrea Righi
2012-10-04 12:12       ` Peter Zijlstra [this message]
2012-10-04 17:19         ` Andrea Righi
2012-10-03 23:05 ` [PATCH RFC 2/3] cpusets: add load avgerage interface Andrea Righi
2012-10-03 23:05 ` [PATCH RFC 3/3] cpusets: add documentation of the loadavg file Andrea Righi

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=1349352728.4438.23.camel@twins \
    --to=peterz@infradead.org \
    --cc=andrea@betterlinux.com \
    --cc=glommer@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=paul@paulmenage.org \
    --cc=pjt@google.com \
    --cc=tglx@linutronix.de \
    /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.