linux-kernel - Re: [RFC][PATCH 1/7] sched: Replace post_schedule with a balance callback list

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]

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/