Re: [Lse-tech] Re: [ckrm-tech] Re: [PATCH 00/01] Move Exit Connectors

[Jes Sorensen <jes@trained-monkey.org>]

>>>>> "Matt" == Matt Helsley <matthltc@us.ibm.com> writes:

Matt> On Wed, 2006-01-11 at 15:39 -0600, John Hesterberg wrote:
>> I have two concerns about an all-tasks notification interface.
>> First, we want this to scale, so don't want more global locks.  One
>> unique part of the task notify is that it doesn't use locks.

Matt> 	Are you against global locks in these paths based solely on
Matt> principle or have you measured their impact on scalability in
Matt> those locations?

Matt,

It all depends on the specific location of the locks and how often
they are taken. As long as something is taken by the same CPU all the
time is not going to be a major issue, but if we end up with anything
resembling a global lock, even if it is only held for a very short
time, it is going to bite badly. On a 4-way you probably won't notice,
but go to a 64-way and it bites, on a 512-way it eats you alive (we
had a problem in the timer code quite a while back that prevented the
machine from booting - it wasn't a lock that was held for a long time,
just the fact that every CPU would take it every HZ was enough).

Matt> 	Without measurement there are two conflicting principles here:
Matt> code complexity vs. scalability.

The two should never be mutually exlusive as long as we are careful.

Matt> 	If you've made measurements I'm curious to know what kind of
Matt> locks were measured, where they were used, what the load was
Matt> doing -- as a rough characterization of the pattern of
Matt> notifications -- and how much it impacted scalability. This
Matt> information might help suggest a better solution.

The one I mentioned above was in the timer interrupt path.

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