[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1193333198.4021.24.camel@ghaskins-t60p.haskins.net>
Date: Thu, 25 Oct 2007 13:26:38 -0400
From: Gregory Haskins <ghaskins@...ell.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: linux-rt-users@...r.kernel.org, linux-kernel@...r.kernel.org,
Dmitry Adamushko <dmitry.adamushko@...il.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Ingo Molnar <mingo@...e.hu>, Darren Hart <dvhltc@...ibm.com>
Subject: Re: [PATCH 3/3] RT: CPU priority management
Oh crap. I just realized this is an older version of the patch..mustv'e
forgot to refresh...grr. Ill send out the refreshed one.
But anyway, I digress.
On Thu, 2007-10-25 at 11:27 -0400, Steven Rostedt wrote:
>
> The cpu_priority and the cp->lock will be aboslutely horrible for
> cacheline bouncing.
In the form presented here in this email, perhaps. I think you will see
some significant improvements in the refreshed version. The big change
is that the global lock is gone.
> Ironically, this will kill performance for the very
> machines this code is to help with. The larger the number of CPUs you
> have the more cacheline bouncing this code will create.
Don't forget: The same is precisely true for the current -rt2
algorithm. For instance, the -rt2 algorithm aside from being linear in
general, scales cacheline bouncing linearly as well. Each cpu is going
to trash rq->rt.highest_prio and then we will walk them for each scan.
The fact is, you can't maintain a global dynamic policy without bouncing
cachelines, period. But hopefully we can minimize it, and I just want
to see the fastest code here.
>
> I still don't see the benefit from the cpupri code.
I still owe you timing data, but at this juncture I think I can beat
linear (especially as we start throwing in big-iron) ;) I originally
got involved in this scheduler rework from observations of poor scaling
on our 8/16-ways, so I want it to scale as much as you ;) If this alg
doesn't pan out, that's cool. But I think it will in the end. Linear
algs in the fast path just make my skin crawl. Perhaps it will still be
the best design in the end, but I am not giving up that easy until I
prove it to myself.
Regards,
-Greg
Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)
Powered by blists - more mailing lists