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.
Sincerely, Gergely Czuczy mailto: [EMAIL PROTECTED] -- Weenies test. Geniuses solve problems that arise.
pgpj6aVLbQZnC.pgp
Description: PGP signature
