[RFC PATCH 0/3] Series short description

Hi Ingo, Steven, Peter,
This series applies roughly to mainline as an enhancement to the sched_rt
logic. Peter and I were discussing some of the unecessary overhead in
pull_rt_tasks() via IRC, and this is my RFC attempt to address the problem.

I have built/booted this on a 4-way C2D Xeon box and it passes preempt-test.

Comments, please.

-Greg

---

Gregory Haskins (3):
sched: use highest_prio.next to optimize pull operations
sched: use highest_prio.curr for pull threshold
sched: track the next-highest priority on each runqueue


kernel/sched.c | 8 ++-
kernel/sched_rt.c | 158 +++++++++++++++++++++++++++++++----------------------
2 files changed, 99 insertions(+), 67 deletions(-)

--
Signature
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

* Gregory Haskins <ghaskins@novell.com> wrote:
[color=blue]
> Hi Ingo, Steven, Peter,
> This series applies roughly to mainline as an enhancement to the sched_rt
> logic. Peter and I were discussing some of the unecessary overhead in
> pull_rt_tasks() via IRC, and this is my RFC attempt to address the problem.
>
> I have built/booted this on a 4-way C2D Xeon box and it passes preempt-test.
>
> Comments, please.[/color]

this direction looks very nifty to me. Peter, do you Ack them?

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

Ingo Molnar wrote:[color=blue]
> * Gregory Haskins <ghaskins@novell.com> wrote:
>
> [color=green]
>> Hi Ingo, Steven, Peter,
>> This series applies roughly to mainline as an enhancement to the sched_rt
>> logic. Peter and I were discussing some of the unecessary overhead in
>> pull_rt_tasks() via IRC, and this is my RFC attempt to address the problem.
>>
>> I have built/booted this on a 4-way C2D Xeon box and it passes preempt-test.
>>
>> Comments, please.
>> [/color]
>
> this direction looks very nifty to me. Peter, do you Ack them?
>
> Ingo
> [/color]
[I just noticed that I fat-fingered the -rt list address, so here is a
link to the thread for those subscribed to -rt]

[url]http://lkml.org/lkml/2008/11/11/193[/url]

-Greg


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - [url]http://enigmail.mozdev.org[/url]

iEYEARECAAYFAkkZ1BcACgkQlOSOBdgZUxnr1gCdESRbOlYbwhQfvGy3/SU/G7p0
6iwAn0UB67EZYd1/06XdiTWeJxa/Tc3S
=vfKT
-----END PGP SIGNATURE-----

Gregory Haskins wrote:[color=blue]
> Hi Ingo, Steven, Peter,
> This series applies roughly to mainline as an enhancement to the sched_rt
> logic. Peter and I were discussing some of the unecessary overhead in
> pull_rt_tasks() via IRC, and this is my RFC attempt to address the problem.
>
> I have built/booted this on a 4-way C2D Xeon box and it passes preempt-test.[/color]

At first blush it looks reasonable, but do you have any performance numbers?

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

Chris Friesen wrote:[color=blue]
> Gregory Haskins wrote:[color=green]
>> Hi Ingo, Steven, Peter,
>> This series applies roughly to mainline as an enhancement to the
>> sched_rt
>> logic. Peter and I were discussing some of the unecessary overhead in
>> pull_rt_tasks() via IRC, and this is my RFC attempt to address the
>> problem.
>>
>> I have built/booted this on a 4-way C2D Xeon box and it passes
>> preempt-test.[/color]
>
> At first blush it looks reasonable, but do you have any performance
> numbers?[/color]

Hi Chris,
That is a perfectly reasonable request, but unfortunately I do not
have any at this time. Its currently all based on the observation that
pull_rt_tasks() can cause excessive rq->lock contention and the theory
that this should reduce the cases where that happens. It still needs to
be proven and quantified, outside of the basic litmus test I gave it
before posting.

I will try to get to this ASAP.

Regards,
-Greg



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - [url]http://enigmail.mozdev.org[/url]

iEYEARECAAYFAkkZ4egACgkQlOSOBdgZUxnEEgCfbc6CY1234HeFa+5Srx6/WQb3
GuYAmwW+km5A4ktQMG33EmZ2UuVtvP/F
=XjUL
-----END PGP SIGNATURE-----