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: <1255511864.8392.370.camel@twins>
Date:	Wed, 14 Oct 2009 11:17:44 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	bharata@...ux.vnet.ibm.com
Cc:	linux-kernel@...r.kernel.org,
	Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>,
	Gautham R Shenoy <ego@...ibm.com>,
	Srivatsa Vaddagiri <vatsa@...ibm.com>,
	Ingo Molnar <mingo@...e.hu>,
	Pavel Emelyanov <xemul@...nvz.org>,
	Herbert Poetzl <herbert@...hfloor.at>,
	Avi Kivity <avi@...hat.com>,
	Chris Friesen <cfriesen@...tel.com>,
	Paul Menage <menage@...gle.com>,
	Mike Waychison <mikew@...gle.com>
Subject: Re: [RFC v2 PATCH 4/8] sched: Enforce hard limits by throttling

On Wed, 2009-10-14 at 09:11 +0530, Bharata B Rao wrote:
> On Tue, Oct 13, 2009 at 04:27:00PM +0200, Peter Zijlstra wrote:
> > On Wed, 2009-09-30 at 18:22 +0530, Bharata B Rao wrote:
> > 
> > > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > > index 0f1ea4a..77ace43 100644
> > > --- a/include/linux/sched.h
> > > +++ b/include/linux/sched.h
> > > @@ -1024,7 +1024,7 @@ struct sched_domain;
> > >  struct sched_class {
> > >     const struct sched_class *next;
> > >  
> > > -   void (*enqueue_task) (struct rq *rq, struct task_struct *p, int wakeup);
> > > +   int (*enqueue_task) (struct rq *rq, struct task_struct *p, int wakeup);
> > >     void (*dequeue_task) (struct rq *rq, struct task_struct *p, int sleep);
> > >     void (*yield_task) (struct rq *rq);
> > >  
> > 
> > I really hate this, it uglfies all the enqueue code in a horrid way
> > (which is most of this patch).
> > 
> > Why can't we simply enqueue the task on a throttled group just like rt?
> 
> We do enqueue a task to its group even if the group is throttled. However such
> throttled groups are not enqueued further. In such scenarios, even though the
> task enqueue to its parent group succeeded, it really didn't add any task to
> the cpu runqueue (rq). So we need to identify this condition and don't
> increment rq->running. That is why this return value is needed.

I would still consider those tasks running, the fact that they don't get
to run is a different matter.

This added return value really utterly craps up the code and I'm not
going to take it.

What I'm not seeing is why all this code looks so very much different
from the rt bits.

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