On Thu, Feb 09, 2012 at 10:59:45AM -0500, Chris Metcalf wrote: > On 2/9/2012 10:52 AM, Frederic Weisbecker wrote: > > On Thu, Feb 02, 2012 at 10:29:57AM -0600, Christoph Lameter wrote: > >> On Thu, 2 Feb 2012, Frederic Weisbecker wrote: > >> > >>>> Some pinned timers might be able to get special treatment as well - take for > >>>> example the vmstat work being schedule every second, what should we do with > >>>> it for CPU isolation? > >>> Right, I remember I saw these vmstat timers on my way when I tried to get 0 > >>> interrupts on a CPU. > >>> > >>> I think all these timers need to be carefully reviewed before doing anything. > >>> But we certainly shouldn't adopt the behaviour of migrating timers by default. > >>> > >>> Some timers really needs to stay on the expected CPU. Note that some > >>> timers may be shutdown by CPU hotplug callbacks. Those wouldn't be migrated > >>> in case of CPU offlining. We need to keep them. > >>> > >>>> It makes sense to me to have that stop scheduling itself when we have the tick > >>>> disabled for both idle and a nohz task. > >> The vmstat timer only makes sense when the OS is doing something on the > >> processor. Otherwise if no counters are incremented and the page and slab > >> allocator caches are empty then there is no need to run the vmstat timer. > > So this is a typical example of a timer we want to shutdown when the CPU is idle > > but we want to keep it running when we run in adaptive tickless mode (ie: shutdown > > the tick while the CPU is busy). > > We would want to stop the timer as long as the processor is running > exclusively userspace code. Christoph's point is that in either the idle > case or the userspace-only case, the vmstats won't be incrementing anyway. > Presumably you'd restart the timer when you enter the kernel, then when it > fires and does its work, you might notice that when you return to userspace > no further information will be collected, so stop the timer at that point. > Or, perhaps you could just proactively call refresh_cpu_vm_stats() just > before stopping the tick and returning "permanently" to userspace, to make > sure the stats are all properly updated. Ah good point. I believe that many timers considered as deferrable during idle may also be considered that way for userspace. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>