Date: Tue, 30 Oct 2007 21:18:22 +0800 From: David Xu <davidxu@FreeBSD.org> To: Kris Kennaway <kris@FreeBSD.org> 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: <47272F1E.7070900@freebsd.org> In-Reply-To: <472701C9.4020208@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote: > David Xu wrote: >> 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, but sched_yield() loops does help it a lot.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47272F1E.7070900>