![]() | ||||||||||
Messages in this thread |
Christian Ehrhardt wrote: > > ... > Both processors succeeded in bringing the page_count to zero, > i.e. both processors will add the page to their own > pages_to_free_list. This is why __pagevec_release() has the refcount check inside the lock. If someone else grabbed a ref to the page (also inside the lock) via the LRU, __pagevec_release doesn't free it. So the rule could be stated as: the page gets freed when there are no references to it, presence on the LRU counts as a reference, serialisation is via pagemap_lru_lock. > .. > > I don't have a fix but I think the only real solution is to > increment the page count if a page is on a lru list. After all > this is a reference to the page. One would think so, but that doesn't really change anything. I agree the locking and reffing in there is really nasty. It doesn't help that I put four, repeat four bugs in the 20-line __page_cache_release(). __pagevec_release() is, I think, OK. It would be much simpler to grab the lock each time page_cache_release() is executed, but our performance targets for 2.5 preclude that. The page->pte.chain != NULL problems predate the locking changes. We haven't found that one yet. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2005-03-22 12:22 [from the cache] ©2003-2008 | ||||||||||