Ray, > On 7/22/07, Michael Kerrisk <[EMAIL PROTECTED]> wrote: > > Problem 1 > > --------- > > > > The value returned by read(2)ing from a timerfd file descriptor is > > the > > number of timer overruns. In 2.6.22, this value is 4 bytes, limiting > > the overrun count to 2^32. Consider an application where the timer > > frequency > > was 100 kHz (feasible in the not-too-distant future, I would guess), > > then > > the overrun counter would cycle after ~40000 seconds (~11 hours). > > Furthermore returning 4 bytes from the read() is inconsistent with > > eventfd > > file descriptors, which return 8 byte integers from a read(). > > I'm feeling slow, and think I'm missing something. Why is this an > issue? Wouldn't userspace just keep track of the last overrun count, > and subtract the two to get the overruns-since-last-read?
The value returned by read() is the number of overruns since the last read(). > That makes > it oblivious to rollovers, unless it can't manage to do a read once > every 11 hours. That's the point that the change is meant to address. > (This is the same sort of thing we already have to deal with in > certain situations, such as network stat counters on 32 bit > platforms.) But userspace can't deal with the condition accurately, so why require userspace to worry about this when we could just use a 64-bit value instead? Cheers, Michael -- Michael Kerrisk maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 Want to help with man page maintenance? Grab the latest tarball at http://www.kernel.org/pub/linux/docs/manpages , read the HOWTOHELP file and grep the source files for 'FIXME'. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
