On Thu, 27 Jun 2013 22:07:12 -0700 Anton Vorontsov <anton@xxxxxxxxxx> wrote: > On Thu, Jun 27, 2013 at 09:34:11PM -0700, Anton Vorontsov wrote: > > ... we can add the strict mode and deprecate the > > "filtering" -- basically we'll implement the idea of requiring that > > userspace registers a separate fd for each level. > > Btw, assuming that more levels can be added, there will be a problem: > imagine that an app hooked up onto low, med, crit levels in "strict" > mode... then once we add a new level, the app will start missing the new > level events. That's how it's expected to work, because on strict mode you're notified for the level you registered for. So apps registering for critical, will still be notified on critical just like before. > In the old scheme it is not a problem because of the >= condition. I think the problem actually lies with the current interface, because if an app registers for critical and we add a new level after critical then this app will now be notified on critical *and* the new level. The app's algorithm might not be prepared to deal with that. > With a proper versioning this won't be a problem for a new scheme too. I don't think there's a problem to be solved here. Strict mode does allow forward compatibility. For good backward compatibility we can make memory.pressure_level return supported levels on read. This way applications can check if the level they are interested in exist and then fallback or exit with a good error message if they don't. -- 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/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>