Changing the notify mechanism again may be a good idea, but I don't know whether it will map easily to the network protocol so this needs more analysis. Since notify is most useful over a network filesystem (if you are running on a local file system, notify is useful but polling is not as expensive as it is over a network, and there are other ways that applications can detect new files). CIFS and SMB2 have a notify mechanism (and Samba server's need to call this led to the initial Linux kernel implementation, which matched fairly closely with the cifs wire protocol) but I don't know if the new mechanism will make it harder or easier to finish the notify support in the cifs client (which is currently turned off in mainline).
Followups: performance counters, ksplice, and fsnotify
Posted Dec 19, 2008 22:50 UTC (Fri) by oak (guest, #2786)
[Link]
> if you are running on a local file system, notify is useful but polling
is not as expensive as it is over a network,
Maybe you were thinking of something tethered to a power cord? For
battery powered devices, polling is evil.
(Before dynticks got into mainstream, Desktop crowd using laptops might
not have noticed / cared, but with dynticks you suddenly start to see how
much less power your laptop uses and how much longer it can run when
polling wakeups get reduced radically.)