Anthony Liguori wrote: > Jan Kiszka wrote: >> Anthony Liguori wrote: >> >>> Marcelo Tosatti wrote: >>> >>>> Jan, >>>> >>>> While the patch itself looks fine, IMO it would be better to move all >>>> of the timer handling to userspace, except the performance critical >>>> parts, >>>> since most of it is generic. Either periodic or one-shot timer, with: >>>> >>> The reason for having the PIT in-kernel is not performance. The PIT is >>> not performance sensitive. >>> >> >> I think that depends. Some OSes (in some configurations) use the PIT >> counter as clock source and/or program it regularly in one-shot mode. An >> aging use case, but still a valid one. >> > > I can't find the thread, but this has been discussed at length before. > The justification has always been for time drift correction. If you > crunch the numbers, even at a 1024HZ, there just aren't enough exits to > really make a difference from a performance perspective. > > Just to state it more clearly, if you assume an additional 5us to drop > to userspace (which is absurdly high, but let's stick with it), 1024 > exits per second comes out to about 5ms which is only 0.5% in terms of > CPU consumption. You are considering timekeeping activities only. RHEL4 for example reads the PIT for each gettimeofday call. For applications that add timestamps to logging the PIT is a *HUGE* overhead (and the PMTMR for that matter). I have one example where something like 15% of each second is wasted handling the ioport reads and writes for get_offset_pit. david > > The APIC is quite a bit more understandable because especially with SMP, > you can generate a very high number of interrupts per second and taking > a drop to userspace for every EOI can be start to matter with exit rates > in the hundreds of thousands. > >>> It's because it was easier to do interrupt catch-up by pushing the PIT >>> into the kernel which IMHO was the wrong path to go down. >>> >> >> Pushing the emulation of port 0x61 into the kernel was a mistake we now >> have to deal with. I'm not that sure about the PIT itself. >> > > I agree re: port 0x61. I'm just saying that there is no point in moving > just the non "performance critical" components to userspace as Marcelo > suggests because the whole thing is non "performance critical". > > Regards, > > Anthony Liguori > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
