>Hi,
>
>On Sat, 26 Sep 1998 19:46:53 +0200 (CEST), Andrea Arcangeli
><andrea@e-mind.com> said:
>
>> Please Alan be _sure_ to not apply my swapin-parent patch to 2.0.36
>> because I had a problem now (it not crashed but I' ve seen some not happy
>> prink and I rebooted istanteneously with 35 because it' s production
>> machine...).
>
>Which printks, exactly?
The one in vmscan:
if ((entry = find_in_swap_cache(MAP_NR(page)))) {
if (page_map->count != 1) {
set_pte(page_table, pte_mkdirty(pte));
printk("Aiee.. duplicated cached swap-cache entry\n");
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
return 0;
}
vma->vm_mm->rss--;
flush_cache_page(vma, address);
set_pte(page_table, __pte(entry));
flush_tlb_page(vma, address);
free_page(page);
return 1;
}
It seems that in 2.0 a swap cache entry has to have page_map[] count == 1.
I have not thought about this printk yet.
>There is a problem with your patch: you effectively fault the parent
>process without taking the mm->mmap_sem lock. Currently, the only code
>which is allowed to do that is the swapout code. I'm not entirely sure
>what the consequences are of doing a swapin without that lock, but I'm
>certain I don't want to risk changing that invariant for 2.0.
Agreed. Anyway I don' t think the mm->mmap lock is the problem.
>I'd still prefer to stay on the safe side and not make any such changes
>at all to 2.0. However, this can be a major performance problem in
Right.
Andrea[s] Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/