On Tue, Jan 01, 2008 at 03:19:29PM +0100, Kris Kennaway wrote: > Vlad GALU wrote: > >On 1/1/08, Kris Kennaway <[EMAIL PROTECTED]> wrote: > >>Gergely CZUCZY wrote: > >>>On Tue, Jan 01, 2008 at 05:04:56AM +0100, Kris Kennaway wrote: > >>>>Ivan Voras wrote: > >>>>>Kris Kennaway wrote: > >>>>>>Gergely CZUCZY wrote: > >>>>>>>>It looks like myisam is doing huge numbers of concurrent reads of the > >>>>>>>>same file which is running into exclusive locking in the kernel > >>>>>>>>(vnode interlock and lockbuilder mtxpool). Does it not do any > >>>>>>>>caching of the data in userspace but relies on querying into the > >>>>>>>>kernel every time? innodb doesn't have this behaviour. > >>>>>>>Sorry, but was this a rethorical kind of question, or was this > >>>>>>>addressed to me? :) > >>>>>>>If the later, then how do I find this out? > >>>>>>It's a general question. It looks like myisam either has a design > >>>>>>deficiency in this regard or it has poor defaults. If it can be made to > >>>>>>improve caching of the data in userland then performance should improve. > >>>>>Isn't this common for software developed for Linux? I mean assuming > >>>>>syscalls are cheap; for example: gettimeofday(2), settitle(2), etc. I > >>>>>don't think the applications should be blamed for relying on performance > >>>>>optimizations not present in FreeBSD. Saying applications must do their > >>>>>own caching instead of relying on the kernel and need to avoid > >>>>>concurrent accesses to the same file seems like a doctrine from the dark > >>>>>ages. > >>>>Why? Even if Linux magically has faster syscalls somehow, they are still > >>>>not zero cost so avoiding huge numbers of unnecessary > >>>>trips > >>>>into the kernel is in no sense a "doctrine from the dark ages". Besides, > >>>>if my hypothesis about the problem is correct then mysql > >>>>itself does this with the alternate innodb backend anyway. > >>>There's this SYSCALL CPU extension with the SYSENTER/SYSEXIT features. IIRC > >>>Linux takes advantage of this, while FreeBSD doesn't. I might be wrong > >>>here, > >>>of course. > >>FreeBSD does on amd64. It still doesn't make syscalls free, so the > >>architectural principle of "cache data close to where it is needed" > >>continues to apply. > >> > >>Anyway, it remains to be understood whether linux really does have > >>faster syscalls, i.e. to understand exactly what unixbench is reporting > >>when it emits pretty numbers. For example, how is it determining > >>"syscall overhead"? Often this is done by calling a syscall that the > >>microbenchmark assumes is doing almost no work in the kernel. This is > >>often chosen to be getpid() which may well be NULL on Linux, but > >>actually does do work on FreeBSD unless you remove COMPAT_43BSD from > >>your kernel. Also I believe glibc caches getpid() in libc (again that > >>pesky architectural principle) so you need to be careful you are > >>actually doing the syscalls you think you are. > >> > > BTW, now with COMPAT_43 gone out of GENERIC, is it necesary to keep > >COMPAT_43TTY, even when Linux emulation is not needed? > > I think a lot of old software (e.g. in ports) still uses it although someone > is working on converting them to less archaic APIs. Is there some wiki pages or any writings on this issue? I'm not so familiar with this COMPAT_43 obsolated stuff, and I'd like to know what's going on, what's the problem, and so on...
Sincerely, Gergely Czuczy mailto: [EMAIL PROTECTED] -- Weenies test. Geniuses solve problems that arise.
pgpqAsq9mErYs.pgp
Description: PGP signature
