Post by John McCabe-DanstedI 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.
------
""""
Post by John McCabe-DanstedI 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.
Post by John McCabe-DanstedI 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