Hi Andrew. On Tue, May 13, 2008 at 11:33:41PM -0700, Andrew Morton (akpm@xxxxxxxxxxxxxxxxxxxx) wrote: > If any thread takes more than one kmap() at a time, it is deadlockable. > Because there is a finite pool of kmaps. Everyone can end up holding > one or more kmaps, then waiting for someone else to release one. It never takes the whole LAST_PKMAP maps. So the same can be applied to any user who kmaps at least one page - while user waits for free slot, it can be reused by someone else and so on. But it can be speed issue, on 32 bit machine with 8gb of ram essentially all pages were highmem and required mapping, so this does slows things down (probably a lot), so I will extend writeback path of the POHMELFS not to kmap pages, but instead use ->sendpage(), which if needed will map page one-by-one. Current approach when page is mapped and then copied looks really beter since the only one sending function is used which takes lock only single time. > Duplicating page_waitqueue() is bad. Exporting it is probably bad too. > Better would be to help us work out why the core kernel infrastructure is > unsuitable, then make it suitable. When ->writepage() is used, it has to wait until page is written (remote side sent acknowledge), so if multiple pages are being written simultaneously we either have to allocate shared structure or use per-page wait. Right now there are transactions (and they will be used for all operations eventually), so this waiting can go away. It is exactly the same logic which lock_page() uses. Will lock_page_killable()/__lock_page_killable() be exported to modules? -- Evgeniy Polyakov -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
