On Tue, Jan 29, 2013 at 04:49:04PM -0600, Seth Jennings wrote: > On 01/29/2013 04:14 PM, Joe Perches wrote: > > On Tue, 2013-01-29 at 15:40 -0600, Seth Jennings wrote: > >> The code required for the flushing is in a separate patch now > >> as requested. > > > > What tree does this apply to? > > Both -next and linus fail to compile. > > Link to build instruction in the cover letter: > > >> NOTE: To build, read this: > >> http://lkml.org/lkml/2013/1/28/586 > > The complexity is due to a conflict with a zsmalloc patch in Greg's > staging tree that has yet to make its way upstream. > > Sorry for the inconvenience. Seth, Please don't ignore previous review if you didn't convince reviewer. I don't want to consume time with arguing trivial things. Copy and Paste from previous discussion from zsmalloc pathset > > > On Fri, Jan 25, 2013 at 11:46:14AM -0600, Seth Jennings wrote: > > >> These patches are the first 4 patches of the zswap patchset I > > >> sent out previously. Some recent commits to zsmalloc and > > >> zcache in staging-next forced a rebase. While I was at it, Nitin > > >> (zsmalloc maintainer) requested I break these 4 patches out from > > >> the zswap patchset, since they stand on their own. > > > > > > [2/4] and [4/4] is okay to merge current zsmalloc in staging but > > > [1/4] and [3/4] is dependent on zswap so it should be part of > > > zswap patchset. > > > > Just to clarify, patches 1 and 3 are _not_ dependent on zswap. They > > just introduce changes that are only needed by zswap. > > I don't think so. If zswap might be not merged, we don't need [1, 3] > at the moment. You could argue that [1, 3] make zsmalloc more flexible > and I agree. BUT I want it when we have needs. It would be not too late. > So [1,3] should be part of zswap patchset. -- Kind regards, Minchan Kim -- 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>