Re: [lc-devel] [linux-mm-cc] Re: Chunk list issues

[Nitin G. <nit...@gm...>]

Hi Sannes,

Asbjørn Sannes wrote:
> Nitin Gupta wrote:
>>
>>>> On 6/28/06, Anderson Briglia <bri...@gm...> wrote:
>>>>>>> I have a doubt related to chunk operations:
>>>>>>>
>>>>>>> - I guess you will use the virtual swap as the compressed
>>>> cache for
>>>>>>> anon pages, right? If yes, how will you swapin/swapout chunks?
>>>> If a
>>>>>>> single chunk points to a portion of a physical page, and the
>>>>>>> swapin/swapout operations handle entire pages of data.
>>>>>> Yes, vswap is for anon pages. I think you are mistaken
>>>> somewhere...I'm not using
>>>>>> bio structs or anything to swapin/out pages from vswap.
>>>>> Ok. Will be possible to transfer pages from vswap to a 'real' swap
>>>> area?
>>>> Yes, but 'procedure' will be same as for transferring a page from a
>>>> swap to any other swap: change it swp_entry_t to have 'type' for other
>>>> swap and it will get written to this second swap.
>>> What will be the factor that determines when/which page will be
>>> migrated from vswap to real swap?
>>>
>> vswap is full. Maybe others but I haven't thought of them yet :P
>>
> 
> What should be considered here is how do we actually "migrate" a page
> like this? Because this isn't done very often normally (how often do you
> add/deactive swap areas) it is my understanding that this is an
> expensive process, which is why we can't really do it, a proposal is to
> instead of having a "vswap" area, that we allocate other physical swap
> areas in advance and do the interception of find_get_page & friends as
> is done in the git tree now. This way, when we need to kick out pages it
> is a very straightforward process, just put it in the pre-allocated swap
> slot. Of course this wastes swap space (probably disk) and doesn't work
> with no swap area at all, so maybe a mix where you can add vswap in some
> other way for no-swap area (where we never kick out pages anyways)
> purely as an swap entry id excercise.
> 

The only expensive step in this "migration" from vswap to real swap disk is 
scan_swap_map() (apart from actual disk write which has to be done anyway), 
which gives you a free swap slot. So, the expense is to run this scan_swap_map() 
twice -- once for vswap then for real swap when migrating pages.

This thing can be improved by fact that swap entry value does not determine 
(unlike for real swaps) where page goes in ccache storage. So, all we need is a 
unique no. every time we call scan_swap_map. For this, we can implement a custom 
scan_swap_map for vswap (and let usual one run for real swap). This can be as 
simple as a stack of free entries and will give us a unique swp_entry_t value 
instantly.  This is already being done in that storage-test module.

This will mitigate the cost of exec two scan_swap_map and your worry ;)

Cheers,
Nitin Gupta