On 11/01/2011 05:43 PM, Andrew Morton wrote:
I will confess to and apologise for dropping the ball on cleancache and frontswap. I was never really able to convince myself that it met the (very vague) cost/benefit test,
I believe that it can, but if it does, we also have to operate under the assumption that the major distros will enable it. This means that "no overhead when not compiled in" is not going to apply to the majority of the users out there, and we need clear numbers on what the overhead is when it is enabled, but not used. We also need an API that can handle arbitrarily heavy workloads, since that is what people will throw at it if it is enabled everywhere. I believe that means addressing some of Andrea's concerns, specifically that the API should be able to handle vectors of pages and handle them asynchronously. Even if the current back-ends do not handle that today, chances are that (if tmem were to be enabled everywhere) people will end up throwing workloads at tmem that pretty much require such a thing. An asynchronous interface would probably be a requirement for something as high latency as encrypted ramster :) API concerns like this are things that should be solved before a merge IMHO, since afterwards we would end up with the "we cannot change the API, because that breaks users" scenario that we always end up finding ourselves in. -- 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>