On 12/26/2011 08:35 PM, KOSAKI Motohiro wrote:
> 2011/12/26 Pavel Emelyanov <xemul@xxxxxxxxxxxxx>:
>> On 12/26/2011 04:05 AM, KOSAKI Motohiro wrote:
>>>> +static unsigned char mincore_pte(struct vm_area_struct *vma, unsigned long addr, pte_t pte)
>>>> +{
>>>> + struct page *pg;
>>>> +
>>>> + pg = vm_normal_page(vma, addr, pte);
>>>> + if (!pg)
>>>> + return 0;
>>>> + else
>>>> + return PageAnon(pg) ? MINCORE_ANON : 0;
>>>> +}
>>>> +
>>>
>>> How do your program handle tmpfs pages (and/or ram device pages)?
>>
>> Do you mean mapped files from tmpfs? Currently just any other file.
>> Do you see problems with this patch wrt tmpfs?
>
> If you don't save mapped file on tmpfs or other volatile devices, the process
> might not restored. The data might already destroyed.
Yes I know this, thanks :\
> The common strategy are two,
>
> 1) save all opened file by different ways.
> 2) save all mapped file even though clean file cache.
>
> In both case, we don't reduce freezed data size. So, I'm interesting
> you strategy.
The tmpfs contents itself is supposed to be preserved, it's not a problem. The problem I'm trying
to solve here is which page from task mappings (i.e. vm_area_struct-s) to save and which not to.
Do the proposed MINCORE_RESIDENT and MINCORE_ANON bits have problems with this from
your POV?
Thanks,
Pavel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>