kvm_read() vs ioctl performance

Julian Elischer julian at elischer.org
Fri Mar 21 21:21:44 PDT 2008

Barney Cordoba wrote:
> --- Julian Elischer <julian at elischer.org> wrote:
>> Barney Cordoba wrote:
>>> --- Julian Elischer <julian at elischer.org> wrote:
>>>> Barney Cordoba wrote:
>>>>> I have an app which reads stats from the kernel
>>>>> periodically, and there can be a lot of
>>>> iterations,
>>>>> sometimes 20,000 or more. I'm thinking of
>>>> converting
>>>>> from an ioctl method to kvm_read(). KVM is
>>>> certainly
>>>>> simpler, but its not clear what overhead is
>>>> involved,
>>>>> since kvm_read() likely has to call the kernel
>>>> also.
>>>>> Does anyone have a handle on the difference in
>>>>> overhead, assuming that the ioctl call is to a
>>>> module
>>>>> which does nothing more than copy the data and
>>>> return?
>>>> tried a shared memory page?
>>> No, but I built a test and kvm_read is 70 times
>>> faster, in
>>> case anyone is interested.
>> cool..
>> the only downside is that we are trying to get away
>> from kvm direct 
>> access. (which is why a shared page might give the
>> same result with a 
>> stable API which is not libkvm... BTW on an SMP
>> machine you have
>> no way to ensure that your stats are coherent if you
>> use libkvm.
> The app is portable, and I'd prefer not to have
> different methods for LINUX and FreeBSD. When you say
> "coherent", what exactly do you mean?

there is no synchronisation between your app and the device.
I dont know what sized structure you are reading but how do you know 
that the device isn't half way through writing it?

A mmapped page would be more portable,
for example done in the way that a video frame buffer is done.
All systems support that sort of semantic the same.
Then you can use memory semaphores to make sure that the stuff is 
consistent, because you can write back.

> Barney
>       ____________________________________________________________________________________
> Never miss a thing.  Make Yahoo your home page. 
> http://www.yahoo.com/r/hs

More information about the freebsd-current mailing list