On Sun, Mar 04, 2007 at 08:13:09PM -0800, Suresh B wrote: > On Mon, Mar 05, 2007 at 03:35:34AM +0100, Nick Piggin wrote: > > On Fri, Mar 02, 2007 at 08:23:32PM -0800, Suresh B wrote: > > > When a logical cpu 'x' already has more than one process running, then > > > most likely > > > the siblings of that cpu 'x' must be busy. Otherwise the idle siblings > > > would have likely(in most of the scenarios) picked up the extra load > > > making > > > the load on 'x' atmost one. > > > > Do you have any stats on this? > > Its more of a theory. There will be some conditions that this won't be true > but > IMO those won't be common cases. > > > > Use this logic to eliminate the siblings status check and minimize the > > > cache > > > misses encountered on a heavily loaded system. > > > > Well it does increase the cacheline footprint a bit, but all cachelines > > should be local to our L1 cache, presuming you don't have any CPUs where > > threads have seperate caches. > > These wakeup's can happen across SMP and NUMA domains. In those cases, most > likely > the sibling runqueue lines won't be in the caches. This has nothing to do with > siblings sharing caches or not.
Oh that's true. > > > > What sort of numbers do you have? > > On a 16 node system, we have seen ~1.25% perf improvement on a database > workload > when we completely short circuited wake_idle(). This patch is trying to comeup > with a best compromise to avoid the cache misses and also minimize the > latenices, > perf impact. Hmm, I wonder what if we only wake_idle if the wakeup comes from this CPU or a sibling? That's probably going to have downsides in some workloads as well, though. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
