Re: raw Vs kernel aio

David Williams wrote: > In article <01bd537d$be79c270$bb3c2ba0@prn100-02-682e>, Bloomberg L.P > <LOGIN_ID@bloomberg.com> writes > >David Williams <djw@smooth1.demon.co.uk> wrote in article > ><NXzCuMAuFDE1Ewdv@smooth1.demon.co.uk>... > >> In article <350CE08F.44902F25@email.mot.com>, LeeKB > >> <qsg0075@email.mot.com> writes > >> >Yes I think you're right. I heard from this same group that UX10.20 > >> >doesn't like KAIO very much. So I would suggest that you allocate enough > >> >INFORMIX AIOvp for your system. > >> >About 2 AIOvps per disk. Use "onstat -g sch" to fine tune AIO. > >> Can anyone from IIUG help, can't we get HP and Informix to get > >> together and fix KAIO under HP? > >What is to fix? On some architectures KAIO outperforms AIO VPs on others > >it does > >not. You just use what works best, no? Or am I being too pragmatic about > >this? > KAIO should always be faster since it results in less context switc > switches. > WHy is it slower on HP? KAIO is slower on DG M88K also. The reason is that on a good (OK, OK) multiprocessing box the AIO VPs may already be active on another physical CPU when the IO request comes in an can service it with no context switch at all and in parallel to the Query on another CPU. On DGUX we and DG found that using Informix Processor Affinity features KAIO was 50% faster than AIO VPs but that AIO VPs were 100% faster still if external affinity utilities were used to affine the AIO VPs, NET VPs, and various administration VPs also (Informix Processor Affinity only affines the CPU VPs) and to affine VPs to groups of CPUs with equal access to local cache and memory; such that AIO VP#1 was affined to a different CPU group than CPU VP#1, etc. I intend to experiment with the same trick on Sun/Solaris soon. Art S. Kagel