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

[Asbjørn Sannes]

Nitin Gupta wrote:
> Hi Sannes,
>
> Asbjørn Sannes wrote:
>> Nitin Gupta wrote:
>>>
>>>>> On 6/28/06, Anderson Briglia <briglia.anderson at gmail.com>
>>>>> 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.
>

I'm  not sure how that is going to work, perhaps I'm missing the point,
scan_swap_map() is for allocating free slots of swap, which is fine.
What will be expensive is finding all those page table entries pointing
to your vswap page to be updated.

Keep in mind I'm talking about the case where you have a swap area
already and the heuristic wants to move a page from the compressed cache
to the disk (say kicking out the least recently used page).


> 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.

Yes, this will take care of the case with no real swap (which was my
weak point).

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

My worry was try_to_unuse() which visits each and every process going
through their memory allocations.

Mvh,
Asbjørn Sannes