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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ