On 12/28/2010 12:54 AM, Mike Galbraith wrote:
On Mon, 2010-12-20 at 17:04 +0100, Mike Galbraith wrote:
On Mon, 2010-12-20 at 10:40 -0500, Rik van Riel wrote:
On 12/17/2010 02:15 AM, Mike Galbraith wrote:
BTW, with this vruntime donation thingy, what prevents a task from
forking off accomplice
On Mon, 2010-12-20 at 17:04 +0100, Mike Galbraith wrote:
> On Mon, 2010-12-20 at 10:40 -0500, Rik van Riel wrote:
> > On 12/17/2010 02:15 AM, Mike Galbraith wrote:
> >
> > > BTW, with this vruntime donation thingy, what prevents a task from
> > > forking off accomplices who do nothing but wait for
On Mon, 2010-12-20 at 10:40 -0500, Rik van Riel wrote:
> On 12/17/2010 02:15 AM, Mike Galbraith wrote:
>
> > BTW, with this vruntime donation thingy, what prevents a task from
> > forking off accomplices who do nothing but wait for a wakeup and
> > yield_to(exploit)?
> >
> > Even swapping vruntime
On 12/17/2010 02:15 AM, Mike Galbraith wrote:
BTW, with this vruntime donation thingy, what prevents a task from
forking off accomplices who do nothing but wait for a wakeup and
yield_to(exploit)?
Even swapping vruntimes in the same cfs_rq is dangerous as hell, because
one party is going backwa
On 12/20/2010 12:50 PM, Mike Galbraith wrote:
>
> > > > Would a kick/hint option be useful?
> > >
> > > Depends on what it does...
> >
> > Let you decide whether you only want to drop a hint and leave it at
> > that, or also attempt a preemption.
>
> Who is "you" in this? the s
On Mon, 2010-12-20 at 12:49 +0200, Avi Kivity wrote:
> On 12/20/2010 12:46 PM, Mike Galbraith wrote:
> > >
> > > However, if I'm all alone on my cpu, and the other task is runnable but
> > > not running, behind some unrelated task, then I do need that task to be
> > > preempted (or to move tasks
On 12/20/2010 12:46 PM, Mike Galbraith wrote:
>
> However, if I'm all alone on my cpu, and the other task is runnable but
> not running, behind some unrelated task, then I do need that task to be
> preempted (or to move tasks around).
So in that case, a pull may be advantageous.
Yes.
> >
On Mon, 2010-12-20 at 12:39 +0200, Avi Kivity wrote:
> On 12/20/2010 12:33 PM, Mike Galbraith wrote:
> > >
> > > Correct. I don't want the other task to run before me, I just don't
> > > want to run before it.
> >
> > OK, so what I gather is that if you can preempt another of your own
> > thread
On 12/20/2010 12:33 PM, Mike Galbraith wrote:
>
> Correct. I don't want the other task to run before me, I just don't
> want to run before it.
OK, so what I gather is that if you can preempt another of your own
threads to get the target to cpu, that would be a good thing whether
he's on the s
On Mon, 2010-12-20 at 11:46 +0200, Avi Kivity wrote:
> On 12/20/2010 11:30 AM, Mike Galbraith wrote:
> > > >
> > > > Because preempting a perfect stranger is not courteous, all tasks have
> > > > to play nice.
> > >
> > > I don't want to preempt anybody, simply make the task run before me.
>
On 12/20/2010 11:30 AM, Mike Galbraith wrote:
> >
> > Because preempting a perfect stranger is not courteous, all tasks have
> > to play nice.
>
> I don't want to preempt anybody, simply make the task run before me.
I thought you wanted to get the target to the cpu asap? You just can't
ha
On Mon, 2010-12-20 at 11:03 +0200, Avi Kivity wrote:
> On 12/20/2010 10:55 AM, Mike Galbraith wrote:
> > > > >
> > > > > I don't want it to run now. I want it to run before some other
> > > task. I
> > > > > don't care if N other tasks run before both. So no godlike powers
> > > > >
On 12/20/2010 10:55 AM, Mike Galbraith wrote:
> > >
> > > I don't want it to run now. I want it to run before some other task.
I
> > > don't care if N other tasks run before both. So no godlike powers
> > > needed, simply a courteous "after you".
> >
> > Ponders that...
> >
On Mon, 2010-12-20 at 10:45 +0200, Avi Kivity wrote:
> On 12/20/2010 10:39 AM, Mike Galbraith wrote:
> > On Sun, 2010-12-19 at 11:19 +0200, Avi Kivity wrote:
> > > On 12/19/2010 12:05 PM, Mike Galbraith wrote:
> >
> > > > > We definitely want to maintain fairness. Both with a dedicated
> > >
On 12/20/2010 10:39 AM, Mike Galbraith wrote:
On Sun, 2010-12-19 at 11:19 +0200, Avi Kivity wrote:
> On 12/19/2010 12:05 PM, Mike Galbraith wrote:
> > > We definitely want to maintain fairness. Both with a dedicated virt
> > > host and with a mixed workload.
> >
> > That makes it di
On Sun, 2010-12-19 at 11:19 +0200, Avi Kivity wrote:
> On 12/19/2010 12:05 PM, Mike Galbraith wrote:
> > > We definitely want to maintain fairness. Both with a dedicated virt
> > > host and with a mixed workload.
> >
> > That makes it difficult to the point of impossible.
> >
> > You want a spe
On Sun, 2010-12-19 at 11:19 +0200, Avi Kivity wrote:
> On 12/19/2010 12:05 PM, Mike Galbraith wrote:
> > That's why you'd drop lag, set to max(se->vruntime, cfs_rq->min_vruntime).
>
> Internal scheduler terminology again, don't follow.
(distance to the fair stick, worthiness to receive cpu)
> >
On 12/19/2010 12:05 PM, Mike Galbraith wrote:
On Sun, 2010-12-19 at 08:21 +0200, Avi Kivity wrote:
> On 12/18/2010 09:06 PM, Mike Galbraith wrote:
> > Hm, so it needs to be very cheap, and highly repeatable.
> >
> > What if: so you're trying to get spinners out of the way right? You
> >
On Sun, 2010-12-19 at 08:21 +0200, Avi Kivity wrote:
> On 12/18/2010 09:06 PM, Mike Galbraith wrote:
> > Hm, so it needs to be very cheap, and highly repeatable.
> >
> > What if: so you're trying to get spinners out of the way right? You
> > somehow know they're spinning, so instead of trying to
On 12/18/2010 09:06 PM, Mike Galbraith wrote:
> > I can see the problem, and I'm not trying to be Mr. Negative here, I'm
> > only trying to point out problems I see with what's been proposed.
> >
> > If the yielding task had a concrete fee he could pay, that would be
> > fine, but he doe
On 12/18/2010 09:13 PM, Mike Galbraith wrote:
On Sat, 2010-12-18 at 19:08 +0200, Avi Kivity wrote:
> On 12/17/2010 09:15 AM, Mike Galbraith wrote:
> > BTW, with this vruntime donation thingy, what prevents a task from
> > forking off accomplices who do nothing but wait for a wakeup and
> >
On Sat, 2010-12-18 at 19:08 +0200, Avi Kivity wrote:
> On 12/17/2010 09:15 AM, Mike Galbraith wrote:
> > BTW, with this vruntime donation thingy, what prevents a task from
> > forking off accomplices who do nothing but wait for a wakeup and
> > yield_to(exploit)?
> >
>
> What's the difference betw
On Sat, 2010-12-18 at 19:02 +0200, Avi Kivity wrote:
> On 12/17/2010 09:51 PM, Mike Galbraith wrote:
> > On Fri, 2010-12-17 at 17:09 +0200, Avi Kivity wrote:
> > > On 12/17/2010 08:56 AM, Mike Galbraith wrote:
> > > > > Surely that makes it a reasonable idea to call yield, and
> > > > > ge
On 12/17/2010 09:15 AM, Mike Galbraith wrote:
BTW, with this vruntime donation thingy, what prevents a task from
forking off accomplices who do nothing but wait for a wakeup and
yield_to(exploit)?
What's the difference between that and forking off accomplices who
run(exploit) directly?
Many
On 12/17/2010 09:51 PM, Mike Galbraith wrote:
On Fri, 2010-12-17 at 17:09 +0200, Avi Kivity wrote:
> On 12/17/2010 08:56 AM, Mike Galbraith wrote:
> > > Surely that makes it a reasonable idea to call yield, and
> > > get one of the other tasks on the current CPU running for
> > > a b
On 12/14/2010 07:22 AM, Peter Zijlstra wrote:
... fixed all the obvious stuff. No idea what the hell I was
thinking while doing that "cleanup" - probably too busy looking
at the tests that I was running on a previous codebase :(
For the next version of the patches, I have switched to your
vers
On Fri, 2010-12-17 at 17:09 +0200, Avi Kivity wrote:
> On 12/17/2010 08:56 AM, Mike Galbraith wrote:
> > > Surely that makes it a reasonable idea to call yield, and
> > > get one of the other tasks on the current CPU running for
> > > a bit?
> >
> > There's nothing wrong with trying to give up t
On 12/17/2010 08:56 AM, Mike Galbraith wrote:
> Surely that makes it a reasonable idea to call yield, and
> get one of the other tasks on the current CPU running for
> a bit?
There's nothing wrong with trying to give up the cpu. It's the concept
of a cross cpu yield_to() that I find mighty s
On Fri, 2010-12-17 at 07:57 +0100, Mike Galbraith wrote:
> On Thu, 2010-12-16 at 14:49 -0500, Rik van Riel wrote:
> > >> +static void yield_to_fair(struct rq *rq, struct task_struct *p)
> > >> +{
> > >> +struct sched_entity *se =&p->se;
> > >> +struct cfs_rq *cfs_rq = cfs_rq_of(se)
On Thu, 2010-12-16 at 14:49 -0500, Rik van Riel wrote:
> On 12/14/2010 01:08 AM, Mike Galbraith wrote:
> >> +EXPORT_SYMBOL_GPL(yield_to);
> >
> > That part looks ok, except for the yield cross cpu bit. Trying to yield
> > a resource you don't have doesn't make much sense to me.
>
> The current t
On 12/14/2010 01:08 AM, Mike Galbraith wrote:
On Mon, 2010-12-13 at 22:46 -0500, Rik van Riel wrote:
diff --git a/kernel/sched.c b/kernel/sched.c
index dc91a4d..6399641 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -5166,6 +5166,46 @@ SYSCALL_DEFINE3(sched_getaffinity, pid_t, pid, unsigne
On Tue, 2010-12-14 at 16:56 +0530, Srivatsa Vaddagiri wrote:
> On Tue, Dec 14, 2010 at 12:03:58PM +0100, Mike Galbraith wrote:
> > On Tue, 2010-12-14 at 15:54 +0530, Srivatsa Vaddagiri wrote:
> > > On Tue, Dec 14, 2010 at 07:08:16AM +0100, Mike Galbraith wrote:
> >
> > > > That part looks ok, exce
On Mon, 2010-12-13 at 22:46 -0500, Rik van Riel wrote:
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 2c79e92..408326f 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1086,6 +1086,8 @@ struct sched_class {
> #ifdef CONFIG_FAIR_GROUP_SCHED
>
On Tue, Dec 14, 2010 at 12:03:58PM +0100, Mike Galbraith wrote:
> On Tue, 2010-12-14 at 15:54 +0530, Srivatsa Vaddagiri wrote:
> > On Tue, Dec 14, 2010 at 07:08:16AM +0100, Mike Galbraith wrote:
>
> > > That part looks ok, except for the yield cross cpu bit. Trying to yield
> > > a resource you d
On Tue, 2010-12-14 at 15:54 +0530, Srivatsa Vaddagiri wrote:
> On Tue, Dec 14, 2010 at 07:08:16AM +0100, Mike Galbraith wrote:
> > That part looks ok, except for the yield cross cpu bit. Trying to yield
> > a resource you don't have doesn't make much sense to me.
>
> So another (crazy) idea is t
On Tue, Dec 14, 2010 at 07:08:16AM +0100, Mike Galbraith wrote:
> > +/*
> > + * Yield the CPU, giving the remainder of our time slice to task p.
> > + * Typically used to hand CPU time to another thread inside the same
> > + * process, eg. when p holds a resource other threads are waiting for.
> >
On Mon, 2010-12-13 at 22:46 -0500, Rik van Riel wrote:
> diff --git a/kernel/sched.c b/kernel/sched.c
> index dc91a4d..6399641 100644
> --- a/kernel/sched.c
> +++ b/kernel/sched.c
> @@ -5166,6 +5166,46 @@ SYSCALL_DEFINE3(sched_getaffinity, pid_t, pid,
> unsigned int, len,
> return ret;
> }
Add a yield_to function to the scheduler code, allowing us to
give the remainder of our timeslice to another thread.
We may want to use this to provide a sys_yield_to system call
one day.
Signed-off-by: Rik van Riel
Signed-off-by: Marcelo Tosatti
---
- move to a per sched class yield_to
- fix t
38 matches
Mail list logo
