Messages in this thread | | | Date | Sun, 22 Aug 2004 17:53:29 -0400 (EDT) | From | Zwane Mwaikambo <> | Subject | Re: [PATCH][1/4] Completely out of line spinlocks / i386 |
| |
On Sun, 22 Aug 2004, Linus Torvalds wrote:
> On Sat, 21 Aug 2004, Zwane Mwaikambo wrote: > > > > Pulled from the -tiny tree, the focus of this patch is for reduced kernel > > image size but in the process we benefit from improved cache performance > > since it's possible for the common text to be present in cache. This is > > probably more of a win on shared cache multiprocessor systems like > > P4/Xeon HT. It's been benchmarked with bonnie++ on 2x and 4x PIII (my > > ideal target would be a 4x+ logical cpu Xeon). > > I _really_ think that if we're going to make spinlocks be out-of-line, > then we need to out-of-line the preemption code too.
Good point, Bill saw a lot of extra saving by moving the preemption code out of line too.
> And at that point I'm more than happy to just make it unconditional, > assuming the profiling thing (which was my only worry) has been verified.
With the readprofile and oprofile changes it's still not that easy to determine which locks are being contended as the samples generally are being charged to the function the lock is being contended in. So some investigation has to be done when looking at profiles. This could be remedied by making the valid PC range include data or, preferably, moving spinlock variables into a special section. That way we can simply report back the lock word during sampling.
> And I suspect that the all-C version is pretty much equivalent to the > assembler one, if you use FASTCALL() to make gcc at least use register > argument passing conventions. The advantage is much clearer code, I'd say.
Yes i agree there and it would probably allow for better optimisation by gcc during call setup.
Thanks, Zwane - 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/
| |