[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1877.10.21.68.23.1282256686.squirrel@linux.intel.com>
Date: Thu, 19 Aug 2010 15:24:46 -0700 (PDT)
From: "Tim Chen" <tim.c.chen@...ux.intel.com>
To: "Ingo Molnar" <mingo@...e.hu>
Cc: "Tim Chen" <tim.c.chen@...ux.intel.com>,
"Linus Torvalds" <torvalds@...ux-foundation.org>,
"Thomas Gleixner" <tglx@...utronix.de>,
Frédéric Weisbecker <fweisbec@...il.com>,
peterz@...radead.org, "Andrew Morton" <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, "Andi Kleen" <ak@...ux.intel.com>,
"Tony Luck" <tony.luck@...el.com>
Subject: Re: [PATCH 1/1] mutex: prevent optimistic spinning from spinning
longer than neccessary (Repost)
> Ingo wrote:
>
> These are some rather impressive speedups!
>
> Have you tried to see what performance effects this change has on
smaller
> boxes? Just to see what flip side (if any) this change has.
>
I've done similar experiments with 2.6.35 kernel on smaller boxes. One is
on a dual-socket Westmere box (12 cores total, with HT). Another
experiment is on an old dual-socket Core 2 box (4 cores total, no HT)
On the 12-core Westmere box, I see a 250% increase for Ingo's mutex-test
program with my mutex patch but no significant difference in aim7's
fserver workload.
On the 4-core Core 2 box, I see the difference with the patch for both
mutex-test and aim7 fserver are negligible.
So far, it seems like the patch has not caused regression on smaller
systems. We'll put it through more workloads to check.
Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists