> From: Dave Hansen [mailto:dave@xxxxxxxx] > Sent: Wednesday, May 15, 2013 2:24 PM > To: Seth Jennings > Cc: Konrad Rzeszutek Wilk; Dan Magenheimer; Andrew Morton; Greg Kroah-Hartman; Nitin Gupta; Minchan > Kim; Robert Jennings; Jenifer Hopper; Mel Gorman; Johannes Weiner; Rik van Riel; Larry Woodman; > Benjamin Herrenschmidt; Joe Perches; Joonsoo Kim; Cody P Schafer; Hugh Dickens; Paul Mackerras; linux- > mm@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxx > Subject: Re: [PATCHv11 3/4] zswap: add to mm/ > > On 05/15/2013 01:09 PM, Seth Jennings wrote: > > On Wed, May 15, 2013 at 02:55:06PM -0400, Konrad Rzeszutek Wilk wrote: > >>> Sorry, but I don't think that's appropriate for a patch in the MM subsystem. > >> > >> 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. > > The issue is not whether it is a loadable module or a driver. Nobody > here is stupid enough to say, "hey, now it's a driver/module, all of the > complex VM interactions are finally fixed!" > > If folks don't want this in their system, there's a way to turn it off, > today, with the sysfs tunables. We don't need _another_ way to turn it > off at runtime (unloading the module/driver). The issue is we KNOW the complex VM interactions are NOT fixed and there has been very very little breadth testing (i.e. across a wide range of workloads, and any attempts to show how much harm can come from enabling it.) That's (at least borderline) acceptable in a driver that can be unloaded, but not in MM code IMHO. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
