> -----Original Message----- > From: penberg@xxxxxxxxx [mailto:penberg@xxxxxxxxx] On Behalf Of ext > Pekka Enberg > Sent: 08 May, 2012 11:03 > To: KOSAKI Motohiro > Cc: Anton Vorontsov; Minchan Kim; Moiseichuk Leonid (Nokia-MP/Espoo); John ... > >> That comes from a real-world requirement. See Leonid's email on the topic: > >> > >> https://lkml.org/lkml/2012/5/2/42 > > > > I know, many embedded guys prefer such timer interval. I also have an > > experience similar logic when I was TV box developer. but I must > > disagree. Someone hope timer housekeeping complexity into kernel. but > > I haven't seen any justification. > > Leonid? The "usleep(timeout); read(vmevent_fd)" will eliminate opportunity to use vmevent API for mobile devices. Developers already have to use heartbeat primitives to align/sync timers and update code which is not always simple to do. But the idea is to have user-space wakeup only if we have something change in memory numbers, thus aligned timers will not help much in vmevent case due to memory situation may change a lot in short time. Short depends from software stack but usually it below 1s. To have use-time and wakeups on good level (below 50Hz by e.g. powertop) and allow cpu switch off timers of such short period like 1s are not allowed. Leonid PS: Sorry, meetings prevent to do interesting things :( I am tracking conversation with quite low understanding how it will be useful for practical needs because user-space developers in 80% cases needs to track simply dirty memory changes i.e. modified pages which cannot be dropped. -- 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