From: Darren Hart <dvhltc@us.ibm.com>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
mingo@redhat.com, hpa@zytor.com, linux-kernel@vger.kernel.org,
rusty@rustcorp.com.au, mingo@elte.hu,
linux-tip-commits@vger.kernel.org
Subject: Re: [tip:core/futexes] futex: use current->time_slack_ns for rt tasks too
Date: Thu, 12 Mar 2009 14:33:28 -0700 [thread overview]
Message-ID: <49B97FA8.1060504@us.ibm.com> (raw)
In-Reply-To: <49B923C4.20901@linux.intel.com>
Arjan van de Ven wrote:
> Peter Zijlstra wrote:
>>>> ---
>>>>
>>>> Subject: sched: adjust timer_slack_ns on scheduler policy change
>>>> From: Peter Zijlstra <a.p.zijlstra@chello.nl>
>>>> Date: Thu Mar 12 15:01:02 CET 2009
>>>>
>>>> Ensure RT tasks have 0 timer slack.
>>>>
>>>> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
>>>> ---
>>>> kernel/sched.c | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> Index: linux-2.6/kernel/sched.c
>>>> ===================================================================
>>>> --- linux-2.6.orig/kernel/sched.c
>>>> +++ linux-2.6/kernel/sched.c
>>>> @@ -5511,10 +5511,12 @@ __setscheduler(struct rq *rq, struct tas
>>>> case SCHED_NORMAL:
>>>> case SCHED_BATCH:
>>>> case SCHED_IDLE:
>>>> + p->timer_slack_ns = p->default_timer_slack_ns;
>>>> p->sched_class = &fair_sched_class;
>>>> break;
>>>> case SCHED_FIFO:
>>>> case SCHED_RR:
>>>> + p->timer_slack_ns = 0;
>>>> p->sched_class = &rt_sched_class;
>>>> break;
>>>> }
>>>>
>>
>> Looking at the default_timer_slack_ns stuff, do we want something like
>> the below?
>
> the original idea was that you had a default slack that you got from
> exec time,
> and then something you could just tweak around yourself independently....
>
> this would throw that out of the window.
It seems to me that changing your scheduling class from userspace would
be reasonable justification to change the timer slack to a default value
for that class. Thoughts?
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
next prev parent reply other threads:[~2009-03-12 21:33 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-12 7:55 [PATCH 0/6] Futex fixes and cleanups Darren Hart
2009-03-12 7:55 ` [PATCH 1/6] Update futex commentary Darren Hart
2009-03-12 10:24 ` [tip:core/futexes] futex: update " Darren Hart
2009-03-12 7:55 ` [PATCH 2/6] Additional (get|put)_futex_key() fixes Darren Hart
2009-03-12 10:16 ` Ingo Molnar
2009-03-12 13:42 ` Thomas Gleixner
2009-03-12 23:22 ` Darren Hart
2009-03-12 10:24 ` [tip:core/futexes] futex: additional " Darren Hart
2009-03-13 0:20 ` Ingo Molnar
2009-03-13 5:46 ` Darren Hart
2009-03-13 0:24 ` [tip:core/urgent] " Darren Hart
2009-03-12 7:55 ` [PATCH 3/6] futex: add double_unlock_hb() Darren Hart
2009-03-12 10:07 ` Peter Zijlstra
2009-03-12 10:10 ` Ingo Molnar
2009-03-12 10:58 ` Thomas Gleixner
2009-03-12 15:13 ` Darren Hart
2009-03-12 10:24 ` [tip:core/futexes] " Darren Hart
2009-03-12 7:55 ` [PATCH 4/6] futex: Use current->time_slack_ns for rt tasks too Darren Hart
2009-03-12 10:11 ` Peter Zijlstra
2009-03-12 10:24 ` [tip:core/futexes] futex: use " Darren Hart
2009-03-12 13:53 ` Arjan van de Ven
2009-03-12 14:02 ` Peter Zijlstra
2009-03-12 14:25 ` Thomas Gleixner
2009-03-12 14:48 ` Peter Zijlstra
2009-03-12 15:01 ` Arjan van de Ven
2009-03-12 21:33 ` Darren Hart [this message]
2009-03-12 21:43 ` Thomas Gleixner
2009-03-12 21:29 ` Darren Hart
2009-03-12 7:56 ` [PATCH 5/6] futex: unlock before returning -EFAULT Darren Hart
2009-03-12 10:13 ` Peter Zijlstra
2009-03-12 10:47 ` Thomas Gleixner
2009-03-12 11:06 ` Peter Zijlstra
2009-03-12 15:15 ` Darren Hart
2009-03-12 22:17 ` Darren Hart
2009-03-12 10:24 ` [tip:core/futexes] " Darren Hart
2009-03-13 0:24 ` [tip:core/urgent] " Darren Hart
2009-03-12 7:56 ` [PATCH 6/6] futex: cleanup fault logic Darren Hart
2009-03-12 10:15 ` Peter Zijlstra
2009-03-12 15:09 ` Darren Hart
2009-03-12 10:25 ` [tip:core/futexes] futex: clean up " Darren Hart
2009-03-12 12:22 ` [PATCH 0/6] Futex fixes and cleanups Ingo Molnar
2009-03-12 15:21 ` Darren Hart
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=49B97FA8.1060504@us.ibm.com \
--to=dvhltc@us.ibm.com \
--cc=arjan@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rusty@rustcorp.com.au \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox