On 03/10/2010 07:19 PM, John McCabe-Dansted wrote: > I understand that swap_free_notify_fn did not make its way into > 2.6.33. I also cannot find it in patch-2.6.34-rc1.bz2. > > "So if you feel like you sent me a pull request bit might have been > over-looked, please point that out to me, but in general the merge window > is over. And as promised, if you left your pull request to the last day of > a two-week window, you're now going to have to wait for the 2.6.35 window." > > Does this mean swap_free_notify_fn will have to wait fo 2.6.35? >
Unfortunately, Linus nacked this swap notify patch. I then sent an alternative approach but nobody commented on that: [PATCH 0/3] ramzswap: Eliminate stale data in compressed memory http://lkml.indiana.edu/hypermail/linux/kernel/1003.0/02368.html [PATCH 1/3] Send callback when a swap slot is freed http://patchwork.kernel.org/patch/83737/ [PATCH 2/3] Add notifiers for swapon and swapoff events http://patchwork.kernel.org/patch/83738/ [PATCH 3/3] Add handlers for swap events http://patchwork.kernel.org/patch/83739/ Also, lot of fixes and cleanups were not pulled from linux-next to mainline tree. On a side note, Linus himself didn't like this approach of creating block device itself (see mail below), so he appears quite reluctant merging any ramzswap patches. ------ """" On Thu, 4 Mar 2010, Nitin Gupta wrote: > > > > I have just prepared patches that add this notify callback to > > 'swap_info_struct'. > > However, this requires notifiers for swapon and swapoff events. I will send > > this > > patch series shortly -- hopefully you will hate it less. That sounds like a better layering, at least. And yeah, having callbacks for swapon/swapoff might be fine. It might also make it possible to do that whole TRIM thing more naturally there than in mm/swapfile.c. >> > > I haven't looked at ramzswap, but I assume it must already do some >> > > readpage/writepage thing in an address_space_operations thing? Or does it >> > > really hook into purely at the block device level? That really sounds >> > > somewhat wrong to begin with. > > > > ramzswap block device(s) use "noqueue" mode of operation as any kind > > of I/O request handling logic etc. will be unnecessary overhead in this > > case. You'll still haev all the crazy bio structure allocation/generation etc. Quite frankly, I suspect you'd be _much_ better off using a 'struct address_space' and catching the reads/writes with a_ops->readpages() etc instead. That way they never turn into block operations, and you always just work directly with "struct page". But hey, as mentioned, I haven't looked at it. There may be reasons you really want ramzswap to be a regular block device. It does cause some odd issues here, though, since mm/swapfile.c is really trying very hard to treat swap _files_ and swap _partitions_ the same, and doesn't want to think of things as a block device (or at least wants to minimize that). Linus """" - Nitin _______________________________________________ linux-mm-cc mailing list [email protected] http://lists.laptop.org/listinfo/linux-mm-cc
