Date: Tue, 30 Oct 2007 18:54:51 +0100 From: Kris Kennaway <kris@FreeBSD.org> To: David Xu <bsddiy@126.com> Cc: Daniel Eischen <deischen@FreeBSD.org>, David Xu <davidxu@FreeBSD.org>, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libthr/thread thr_mutex.c src/lib/libkse/thread thr_mutex.c src/include pthread.h Message-ID: <47276FEB.2030202@FreeBSD.org> In-Reply-To: <47272E64.4080607@126.com> References: <200710292101.l9TL1mAE049561@repoman.freebsd.org> <47268F17.1000106@freebsd.org> <Pine.GSO.4.64.0710292207140.19572@sea.ntplx.net> <47269AD0.3080906@freebsd.org> <4726EEFB.8030309@FreeBSD.org> <4726F3C7.2060506@freebsd.org> <472701C9.4020208@FreeBSD.org> <47272E64.4080607@126.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Xu wrote: > Kris Kennaway wrote: > <snip> > >>> My last commit improves mysql select-smack benchmark on 4-core xeon from >>> 48000 queries/s to 70000 queries/s, so my work is alternative way >> >> No, that is an orthogonal issue that (after measurement) does not >> solve the same problem that is addressed by this change. I'd be happy >> to discuss it with you in more detail if you are interested. We could >> also discuss the fact that super-smack is a questionable target to be >> optimizing because the main performance problems seem to be from a >> very poor benchmark design. >> >> I claim that real-world applications do not commonly do I/O in units >> of 1 byte :) > > I'd rather to believe it is scheduling problem, spin loops does not help > it, but sched_yield() loops does help it a lot. Sure, maybe. It's still a completely orthogonal problem. Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47276FEB.2030202>