From: Pekka Enberg on
Nitin Gupta wrote:
> Currently, each ramzswap device can be assigned
> a separate 'backing swap' file/partition. The ramzswap
> driver forwards swap I/O requests to this backing swap
> whenever an incompressible page is found.
>
> This feature adds nearly 700 lines of code and it
> also duplicates much of the swapon() functionality
> (for example, finding swap extents and so on). Removing
> this code makes the driver much simpler and should
> help its transition from staging to stable drivers
> area (drivers/block/).
>
> Similar functionality may be implemented if we can
> implement migrating pages across swap devices but the
> details have not yet been worked out.
>
> Support for _partitions_ as backing swap could be
> retained as it requires a few lines of code only.
> This part can be re-introduced later if above swap
> migration method turns out to be infeasible.
>
> More cleanups and code comments will be added soon.
>
> Signed-off-by: Nitin Gupta <ngupta(a)vflare.org>

Acked-by: Pekka Enberg <penberg(a)cs.helsinki.fi>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Minchan Kim on
Hi, Nitin.

First of all, I am sorry for not review your code.
Now, I am too busy to review your code.

When you send the patch which notify free from swap slot,
I thought it's good except one.

One thing was about naming.
Now block device operations has field naming swap_xxx_notify
(I am not sure exact name). My concern was it's very specific about swap.
So I thought we would be better to more abstract name.

I thought trim like naming as Linus said.

Anyway, I will review again at next week if it isn't merged
linux-next(or linux-mm ?? which is right?). That's because I have a
interest in your good ramzswap. :)

Sorry for late response.
See you soon.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Nitin Gupta on
Hi Minchan,

On 05/16/2010 09:50 AM, Minchan Kim wrote:

> One thing was about naming.
> Now block device operations has field naming swap_xxx_notify
> (I am not sure exact name). My concern was it's very specific about swap.
> So I thought we would be better to more abstract name.
>
> I thought trim like naming as Linus said.

This call is very swap specific and is quite different from generic trim
stuff. So, I think it will be better not be generalize the name and avoid
confusing it with trim/discard etc.

>
> Anyway, I will review again at next week if it isn't merged
> linux-next(or linux-mm ?? which is right?). That's because I have a
> interest in your good ramzswap. :)
>

Thanks, comments/reviews are always welcome :)

Greg: In the meantime, considering 3 Acks, is it possible to pull it in
linux-next?

I can then send additional patches, if you raise any concerns that needs
further code changes.

Thanks,
Nitin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on
On Sun, May 16, 2010 at 09:13:46PM +0530, Nitin Gupta wrote:
> Hi Minchan,
>
> On 05/16/2010 09:50 AM, Minchan Kim wrote:
>
> > One thing was about naming.
> > Now block device operations has field naming swap_xxx_notify
> > (I am not sure exact name). My concern was it's very specific about swap.
> > So I thought we would be better to more abstract name.
> >
> > I thought trim like naming as Linus said.
>
> This call is very swap specific and is quite different from generic trim
> stuff. So, I think it will be better not be generalize the name and avoid
> confusing it with trim/discard etc.
>
> >
> > Anyway, I will review again at next week if it isn't merged
> > linux-next(or linux-mm ?? which is right?). That's because I have a
> > interest in your good ramzswap. :)
> >
>
> Thanks, comments/reviews are always welcome :)
>
> Greg: In the meantime, considering 3 Acks, is it possible to pull it in
> linux-next?

It's already there, right?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Nitin Gupta on
On 05/16/2010 09:51 PM, Greg KH wrote:
> On Sun, May 16, 2010 at 09:13:46PM +0530, Nitin Gupta wrote:
>> Hi Minchan,
>>
>> On 05/16/2010 09:50 AM, Minchan Kim wrote:
>>
>>> One thing was about naming.
>>> Now block device operations has field naming swap_xxx_notify
>>> (I am not sure exact name). My concern was it's very specific about swap.
>>> So I thought we would be better to more abstract name.
>>>
>>> I thought trim like naming as Linus said.
>>
>> This call is very swap specific and is quite different from generic trim
>> stuff. So, I think it will be better not be generalize the name and avoid
>> confusing it with trim/discard etc.
>>
>>>
>>> Anyway, I will review again at next week if it isn't merged
>>> linux-next(or linux-mm ?? which is right?). That's because I have a
>>> interest in your good ramzswap. :)
>>>
>>
>> Thanks, comments/reviews are always welcome :)
>>
>> Greg: In the meantime, considering 3 Acks, is it possible to pull it in
>> linux-next?
>
> It's already there, right?
>

Yuk! its there.

I actually wanted to refer to the 'swap notify patch'. Please see patch titled:
'ramzswap: Eliminate stale data from compressed memory (v2)'
(http://thread.gmane.org/gmane.linux.kernel/982232)

This patch got 3 Acks: Pekka, Linus and Nigel.

(Minchan, please always reply to the patch your are referring to)

Thanks,
Nitin


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/