On Fri, Oct 28, 2011 at 10:07:12AM -0700, Dan Magenheimer wrote: > > > From: Johannes Weiner [mailto:jweiner@xxxxxxxxxx] > > Subject: Re: [GIT PULL] mm: frontswap (for 3.2 window) > > > > On Fri, Oct 28, 2011 at 06:36:03PM +0300, Pekka Enberg wrote: > > > On Fri, Oct 28, 2011 at 6:21 PM, Dan Magenheimer > > > <dan.magenheimer@xxxxxxxxxx> wrote: > > > Looking at your patches, there's no trace that anyone outside your own > > > development team even looked at the patches. Why do you feel that it's > > > OK to ask Linus to pull them? > > > > People did look at it. > > > > In my case, the handwavy benefits did not convince me. The handwavy > > 'this is useful' from just more people of the same company does not > > help, either. > > > > I want to see a usecase that tangibly gains from this, not just more > > marketing material. Then we can talk about boring infrastructure and > > adding hooks to the VM. > > > > Convincing the development community of the problem you are trying to > > solve is the undocumented part of the process you fail to follow. > > Hi Johannes -- > > First, there are several companies and several unaffiliated kernel > developers contributing here, building on top of frontswap. I happen > to be spearheading it, and my company is backing me up. (It > might be more appropriate to note that much of the resistance comes > from people of your company... but please let's keep our open-source > developer hats on and have a technical discussion rather than one > which pleases our respective corporate overlords.) I didn't mean to start a mud fight about this, I only mentioned the part about your company because I already assume it sees value in tmem - it probably wouldn't fund its development otherwise. I just tend to not care too much about Acks from the same company as the patch itself and I believe other people do the same. > Second, have you read http://lwn.net/Articles/454795/ ? > If not, please do. If yes, please explain what you don't > see as convincing or tangible or documented. All of this > exists today as working publicly available code... it's > not marketing material. I remember answering this to you in private already some time ago when discussing frontswap. You keep proposing a bridge and I keep asking for proof that this is not a bridge to nowhere. Unless that question is answered, I am not interested in discussing the bridge's design. According to the LWN article, there are the following backends: 1. Zcache: allow swapping into compressed memory This sets aside a portion of memory which the kernel will swap compressed pages into upon pressure. Now, obviously, reserving memory from the system for this increases the pressure in the first place, eating away on what space we have for anonymous memory and page cache. Do you auto-size that region depending on workload? If so, how? If not, is it documented how to size it manually? Where are the performance numbers for various workloads, including both those that benefit from every bit of page cache and those that would fit into memory without zcache occupying space? However, looking at the zcache code, it seems it wants to allocate storage pages only when already trying to swap out. Are you sure this works in reality? 2. RAMster: allow swapping between machines in a cluster Are there people using it? It, too, sounds like a good idea but I don't see any proof it actually works as intended. 3. Xen: allow guests to swap into the host. The article mentions that there is code to put the guests under pressure and let them swap to host memory when the pressure is too high. This sounds useful. Where is the code that controls the amount of pressure put on the guests? Where are the performance numbers? Surely you can construct a case where the initial machine sizes are not quite right and then collect data that demonstrates the machines are rebalancing as expected? 4. kvm: same as Xen Apart from the questions that already apply to Xen, I remember KVM people in particular complaining about the synchroneous single-page interface that results in a hypercall per swapped page. What happened to this concern? --- I would really appreciate if you could pick one of those backends and present them as a real and practical solution to real and practical problems. With documentation on configuration and performance data of real workloads. We can discuss implementation details like how memory is exchanged between source and destination when we come to it. I am not asking for just more code that uses your interface, I want to know the real value for real people of the combination of all that stuff. With proof, not just explanations of how it's supposed to work. Until you can accept that, please include Nacked-by: Johannes Weiner <hannes@xxxxxxxxxxx> on all further stand-alone submissions of tmem core code and/or hooks in the VM. Thanks. -- 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>