> From: Rik van Riel [mailto:riel@xxxxxxxxxx] > Subject: Re: [PATCHv11 3/4] zswap: add to mm/ > > On 05/15/2013 03:35 PM, Dan Magenheimer wrote: > >> From: Konrad Rzeszutek Wilk > >> Subject: Re: [PATCHv11 3/4] zswap: add to mm/ > >> > >>> Sorry, but I don't think that's appropriate for a patch in the MM subsystem. > >> > >> I am heading to the airport shortly so this email is a bit hastily typed. > >> > >> Perhaps a compromise can be reached where this code is merged as a driver > >> not a core mm component. There is a high bar to be in the MM - it has to > >> work with many many different configurations. > >> > >> And drivers don't have such a high bar. They just need to work on a specific > >> issue and that is it. If zswap ended up in say, drivers/mm that would make > >> it more palpable I think. > >> > >> Thoughts? > > > > Hmmm... > > > > To me, that sounds like a really good compromise. > > Come on, we all know that is nonsense. > > Sure, the zswap and zbud code may not be in their final state yet, > but they belong in the mm/ directory, together with the cleancache > code and all the other related bits of code. > > Lets put them in their final destination, and hope the code attracts > attention by as many MM developers as can spare the time to help > improve it. Hi Rik -- Seth has been hell-bent on getting SOME code into the kernel for over a year, since he found out that enabling zcache, a staging driver, resulted in a tainted kernel. First it was promoting zcache+zsmalloc out of staging. Then it was zswap+zsmalloc without writeback, then zswap+zsmalloc with writeback, and now zswap+zbud with writeback but without a sane policy for writeback. All of that time, I've been arguing and trying to integrate compression more deeply and sensibly into MM, rather than just enabling compression as a toy that happens to speed up a few benchmarks. (This, in a nutshell, was the feedback I got at LSFMM12 from Andrea and Mel... and I think also from you.) Seth has resisted every step of the way, then integrated the functionality in question, adapted my code (or Nitin's), and called it his own. If you disagree with any of my arguments earlier in this thread, please say so. Else, please reinforce that the MM subsystem needs to dynamically adapt to a broad range of workloads, which zswap does not (yet) do. Zswap is not simple, it is simplistic*. IMHO, it may be OK for a driver to be ham-handed in its memory use, but that's not OK for something in mm/. So I think merging zswap as a driver is a perfectly sensible compromise which lets Seth get his code upstream, allows users (and leading-edge distros) to experiment with compression, avoids these endless arguments, and allows those who care to move forward on how to deeply integrate compression into MM. Dan * simplistic, n., The tendency to oversimplify an issue or a problem by ignoring complexities or complications. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
