From: Peter Zijlstra <peterz@infradead.org>
To: Paul Turner <pjt@google.com>
Cc: "Jan H. Schönherr" <schnhrr@cs.tu-berlin.de>,
"Ingo Molnar" <mingo@elte.hu>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] sched: Enforce order of leaf CFS runqueues
Date: Tue, 19 Jul 2011 15:08:41 +0200 [thread overview]
Message-ID: <1311080921.13765.203.camel@twins> (raw)
In-Reply-To: <CAPM31RLqq0hgdhoh3GA-38petKeE1zxcL=uJYba9o3yd+_7jjw@mail.gmail.com>
On Mon, 2011-07-18 at 16:24 -0700, Paul Turner wrote:
> Subject: [PATCH] sched: handle on_list ancestor in leaf_add_cfs_rq()
> From: Paul Turner <pjt@google.com>
> Date: Mon, 18 Jul 2011 16:08:10 -0700
>
> Jan H. Schönherr found that in the case of an on_list ancestor we may
> incorrectly place the child to the right of a great-ancestor on the list.
>
> Consider:
>
> A
> / \ Here, t1A results in A->cfs_rq being on_list, however when
> B t1A we start enqueuing from C this will not be visible. This is
> / compounded by the fact that on_list expiration may also be out
> C of order, punching holes in the tree.
> /
> t1C
>
> Prevent this by making additions to the leaf_cfs_rq_list position independent.
> This is done by maintaining additions to this list within the
> enqueue_task_fair() path, which allows us to always enqueue against the
> current entity's first on_list ancestor.
The problem I have with this is that it makes the enqueue more
expensive. We're now optimizing a relatively slow path (load-balance) at
the cost of the hottest path in the kernel (enqueue/dequeue).
next prev parent reply other threads:[~2011-07-19 13:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-18 10:50 [PATCH 0/2] Enforce hierarchical order of leaf CFS runqueues Jan H. Schönherr
2011-07-18 10:50 ` [PATCH 1/2] sched: Enforce " Jan H. Schönherr
2011-07-18 23:24 ` Paul Turner
2011-07-19 13:08 ` Peter Zijlstra [this message]
2011-07-19 17:48 ` Paul Turner
2011-07-19 15:17 ` Jan Schönherr
2011-07-19 17:53 ` Paul Turner
2011-07-21 13:20 ` Jan H. Schönherr
2011-07-21 13:20 ` [PATCH RFC 1/3] list, treewide: Rename __list_del() to __list_link() Jan H. Schönherr
2011-07-21 13:20 ` [PATCH RFC 2/3] rcu: More rcu-variants for list manipulation Jan H. Schönherr
2011-07-22 16:21 ` Paul E. McKenney
2011-07-23 18:41 ` Jan Schönherr
2011-07-21 13:20 ` [PATCH RFC 3/3] sched: Handle on_list ancestor in list_add_leaf_cfs_rq() Jan H. Schönherr
2011-07-18 10:50 ` [PATCH 2/2] sched: Prevent removal of leaf CFS runqueues with on_list children Jan H. Schönherr
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=1311080921.13765.203.camel@twins \
--to=peterz@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pjt@google.com \
--cc=schnhrr@cs.tu-berlin.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.