[linux-mm-cc] Cannot find swap_free_notify_fn in patch-2.6.34-rc1.bz2.

[Nitin Gupta]

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