On 21/01/2008, Christian Boon <chris.boon@xxxxxxxxx> wrote: > Jesper Juhl schreef: > > On 21/01/2008, Christian Boon <chris.boon@xxxxxxxxx> wrote: > > > >> Jesper Juhl schreef: > >> > >>> On 21/01/2008, Christian Boon <chris.boon@xxxxxxxxx> wrote: > >>> > >>> > >>>> Hello, > >>>> > >>>> For my ARM processor (PXA255) i use kernel 2.6.22 and a kernel HZ value > >>>> of 1000. > >>>> > >>>> > >>> [snip] > >>> > >>> > >>>> Am i doing something wrong here? Is this value converted to some sort of > >>>> userspace HZ? > >>>> I have tried it on x86 also and it gives the same behaviour. > >>>> > >>>> > >>>> > >>> In old kernels the HZ value (in both kernel- and user-space) was 100 > >>> without the ability to change this. > >>> When the kernel added the option of other HZ values this was > >>> implemented as kernel-space only and the HZ value exposed to > >>> user-space was fixed at 100. This was done to avoid breaking > >>> applications that assumed a fixed HZ of 100. > >>> So, while the kernel may tick at 100, 250, 1000 or some other HZ > >>> values (or even be tick less), user-space will always see HZ as being > >>> 100. > >>> > >>> > >>> > >> Ok thanks, > >> is there another way to receive the tick counter in userspace? > >> > >> > > > > I don't know of one, but that doesn't mean there isn't any :) > > > > But, why does your application care? > > If it needs to sleep for some amount of time it should just do so with > > sleep(), usleep(), select() or similar - it shouldn't need to know > > what the kernel Hz is... > > If it needs to know the amount of wall-clock time that has passed, > > then calling gettimeofday(), at intervals, is usually good enough. > > I'm currious as to why you need this...? > > > In my application i use a shared memory segment with multiple clients > connected. > I wanted to use the tick value as change counter. > So, you want to know how many kernel ticks have passed and use that as some kind of indication about the state of your shared memory? That doesn't sound very reliable. If you want to keep track of changes to your shared memory segment and know how many changes have happened and/or whether or not the shared memory is in a consistent state or not, then I'd suggest that your application should keep track of this itself - use shared locks, and shared (lock protected) counters in your application to keep track of whether or not it is safe to modify the memory and how many changes have been made to it etc. At what rate the kernel ticks seems to me to be completely irrelevant to that problem. -- Jesper Juhl <jesper.juhl@xxxxxxxxx> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
