From: Rik van Riel <riel@redhat.com>
To: Venkatesh Pallipadi <venki@google.com>
Cc: mingo@redhat.com, hpa@zytor.com, linux-kernel@vger.kernel.org,
a.p.zijlstra@chello.nl, mtosatti@redhat.com, efault@gmx.de,
tglx@linutronix.de, mingo@elte.hu
Subject: Re: [tip:sched/core] sched: Add yield_to(task, preempt) functionality
Date: Sat, 26 Feb 2011 00:44:38 -0500 [thread overview]
Message-ID: <4D689346.1090002@redhat.com> (raw)
In-Reply-To: <AANLkTi=b-tyXEUfBKJH1RbENsqq8a-NRF54dSS6E3WGf@mail.gmail.com>
On 02/25/2011 07:43 PM, Venkatesh Pallipadi wrote:
> On Thu, Feb 3, 2011 at 6:12 AM, tip-bot for Mike Galbraith
> <efault@gmx.de> wrote:
>> Commit-ID: d95f412200652694e63e64bfd49f0ae274a54479
>> Gitweb: http://git.kernel.org/tip/d95f412200652694e63e64bfd49f0ae274a54479
>> Author: Mike Galbraith<efault@gmx.de>
>> AuthorDate: Tue, 1 Feb 2011 09:50:51 -0500
>> Committer: Ingo Molnar<mingo@elte.hu>
>> CommitDate: Thu, 3 Feb 2011 14:20:33 +0100
>>
>> sched: Add yield_to(task, preempt) functionality
>
> I was looking at this patch, while trying to figure out how best to
> use next buddy to solve another unrelated to this cgroup context
> switching problem. While going through this change I see something
> that I don't really understand (inlined below). Not sure whether what
> I am looking at is a bug or I am missing something very obvious.
>
> Thanks in advance for clarification.
>
>>
>> Currently only implemented for fair class tasks.
>>
>> Add a yield_to_task method() to the fair scheduling class. allowing the
>> caller of yield_to() to accelerate another thread in it's thread group,
>> task group.
>>
>
> <snip>
>
>>
>> static void calc_load_account_idle(struct rq *this_rq);
>> @@ -5448,6 +5481,58 @@ void __sched yield(void)
>> }
>> EXPORT_SYMBOL(yield);
>>
>> +/**
>> + * yield_to - yield the current processor to another thread in
>> + * your thread group, or accelerate that thread toward the
>> + * processor it's on.
>> + *
>> + * It's the caller's job to ensure that the target task struct
>> + * can't go away on us before we can do any checks.
>> + *
>> + * Returns true if we indeed boosted the target task.
>> + */
>> +bool __sched yield_to(struct task_struct *p, bool preempt)
>> +{
>> + struct task_struct *curr = current;
>> + struct rq *rq, *p_rq;
>> + unsigned long flags;
>> + bool yielded = 0;
>> +
>> + local_irq_save(flags);
>> + rq = this_rq();
>> +
>> +again:
>> + p_rq = task_rq(p);
>> + double_rq_lock(rq, p_rq);
>> + while (task_rq(p) != p_rq) {
>> + double_rq_unlock(rq, p_rq);
>> + goto again;
>> + }
>> +
>> + if (!curr->sched_class->yield_to_task)
>> + goto out;
>> +
>> + if (curr->sched_class != p->sched_class)
>> + goto out;
>> +
>> + if (task_running(p_rq, p) || p->state)
>> + goto out;
>> +
>> + yielded = curr->sched_class->yield_to_task(rq, p, preempt);
>> + if (yielded)
>> + schedstat_inc(rq, yld_count);
>> +
>> +out:
>> + double_rq_unlock(rq, p_rq);
>> + local_irq_restore(flags);
>> +
>> + if (yielded)
>> + schedule();
>> +
>> + return yielded;
>> +}
>> +EXPORT_SYMBOL_GPL(yield_to);
>> +
>> /*
>> * This task is about to go to sleep on IO. Increment rq->nr_iowait so
>> * that process accounting knows that this is a task in IO wait state.
>> diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
>> index c0fbeb9..0270246 100644
>> --- a/kernel/sched_fair.c
>> +++ b/kernel/sched_fair.c
>> @@ -1975,6 +1975,25 @@ static void yield_task_fair(struct rq *rq)
>> set_skip_buddy(se);
>> }
>>
>> +static bool yield_to_task_fair(struct rq *rq, struct task_struct *p, bool preempt)
>> +{
>> + struct sched_entity *se =&p->se;
>> +
>> + if (!se->on_rq)
>> + return false;
>> +
>> + /* Tell the scheduler that we'd really like pse to run next. */
>> + set_next_buddy(se);
>
> The below comment says about rescheduling p's CPU. But the rq variable
> we have here is the curr_rq and not p_rq. So, should this be done in
> yield_to() with p_rq. I did try to see the discussion on other
> versions of this patch. v3 and before had -
> "resched_task(task_of(p_cfs_rq->curr));" which seems to be correct...
You are correct. We are calling resched_task on the wrong task,
we should call it on p's runqueue's current task...
>> +
>> + /* Make p's CPU reschedule; pick_next_entity takes care of fairness. */
>> + if (preempt)
>> + resched_task(rq->curr);
--
All rights reversed
next prev parent reply other threads:[~2011-02-26 5:45 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-01 14:44 [PATCH -v8a 0/7] directed yield for Pause Loop Exiting Rik van Riel
2011-02-01 14:47 ` [PATCH -v8a 1/7] sched: check the right ->nr_running in yield_task_fair Rik van Riel
2011-02-03 14:11 ` [tip:sched/core] sched: Check the right ->nr_running in yield_task_fair() tip-bot for Rik van Riel
2011-02-01 14:48 ` [PATCH -v8a 2/7] sched: limit the scope of clear_buddies Rik van Riel
2011-02-03 14:11 ` [tip:sched/core] sched: Limit " tip-bot for Rik van Riel
2011-02-01 14:50 ` [PATCH -v8a 4/7] sched: Add yield_to(task, preempt) functionality Rik van Riel
2011-02-01 15:52 ` Peter Zijlstra
2011-02-03 12:58 ` Peter Zijlstra
2011-02-03 14:12 ` [tip:sched/core] " tip-bot for Mike Galbraith
2011-02-26 0:43 ` Venkatesh Pallipadi
2011-02-26 5:44 ` Rik van Riel [this message]
2011-02-28 9:26 ` Mike Galbraith
2011-03-02 0:28 ` [PATCH] sched: resched proper CPU on yield_to Venkatesh Pallipadi
2011-03-02 3:33 ` Rik van Riel
2011-03-02 3:37 ` Venkatesh Pallipadi
2011-03-02 3:52 ` Rik van Riel
2011-03-04 11:50 ` [tip:sched/core] sched: Resched proper CPU on yield_to() tip-bot for Venkatesh Pallipadi
2011-02-01 14:51 ` [PATCH -v8a 3/7] sched: use a buddy to implement yield_task_fair Rik van Riel
2011-02-01 15:53 ` Peter Zijlstra
2011-02-03 12:58 ` Peter Zijlstra
2011-02-03 14:12 ` [tip:sched/core] sched: Use a buddy to implement yield_task_fair() tip-bot for Rik van Riel
2011-02-01 14:51 ` [PATCH -v8a 5/7] export pid symbols needed for kvm_vcpu_on_spin Rik van Riel
2011-02-01 14:52 ` [PATCH -v8a 6/7] kvm: keep track of which task is running a KVM vcpu Rik van Riel
2011-02-01 14:53 ` [PATCH -v8a 7/7] kvm: use yield_to instead of sleep in kvm_vcpu_on_spin Rik van Riel
2011-02-07 9:08 ` [PATCH -v8a 0/7] directed yield for Pause Loop Exiting Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D689346.1090002@redhat.com \
--to=riel@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=efault@gmx.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=mtosatti@redhat.com \
--cc=tglx@linutronix.de \
--cc=venki@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.