[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <OFC07DB1D2.0A9D2900-ON48257E5B.00205930-48257E5B.0027B1CE@zte.com.cn>
Date: Fri, 5 Jun 2015 15:13:38 +0800
From: pang.xunlei@....com.cn
To: Peter Zijlstra <peterz@...radead.org>
Cc: juri.lelli@...il.com, ktkhai@...allels.com,
linux-kernel@...r.kernel.org, mingo@...e.hu, oleg@...hat.com,
pang.xunlei@...aro.org, rostedt@...dmis.org,
umgwanakikbuti@...il.com
Subject: Re: [RFC][PATCH 1/7] sched: Replace post_schedule with a balance callback
list
Hi Peter,
Peter Zijlstra <peterz@...radead.org> wrote 2015-06-03 PM 04:55:27:
>
> Re: [RFC][PATCH 1/7] sched: Replace post_schedule with a balance
callback list
>
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
Sure, will follow. Thanks for the reminding.
>
> On Wed, Jun 03, 2015 at 04:24:05PM +0800, pang.xunlei@....com.cn wrote:
> > Hi Peter,
> >
> > This may increase the overhead of schedule() a bit, as it will have
> > more work to do.
>
> How so? It replaces the post_schedule() muck and should not be more
> expensive than that.
>
> It will make sched_setscheduler() etc.. a little more expensive, but
> that doesn't matter, those are not critical things at all.
Another side effect it may have is that it will introduce some latency,
because we have to wait for next schedule() point to do the balancing.
prio_changed_rt()->pull_rt_task() is not rare cases when using PI futex.
-Xunlei
>
> > check_class_changed():
> > if (prev_class->switched_from)
> > prev_class->switched_from(rq, p);
> > /* Possble rq->lock 'hole'. */
> > p->sched_class->switched_to(rq, p);
> >
> > For above cases, why can't we just add a judgement in
switched_to_fair()
> > as follows:
> > if (rq != task_rq(p))
> > return;
>
> Because its too easy to get wrong. There have been many instances of
> bugs caused by this dropping of rq->lock.
>
> And sure you can patch it up, once you find it, but I would really
> rather prevent these things if at all possible.
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately.
--
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/
Powered by blists - more mailing lists