On Wed, 2009-11-18 at 19:31 +0900, Minchan Kim wrote: > > > > Sure some generic blocklevel infrastructure might work, _but_ you cannot > > take away the responsibility of determining the amount of memory needed, > > nor does any of this have any merit if you do not limit yourself to that > > amount. > > Yes. Some one have to take a responsibility. > > The intention was we could take away the responsibility from block driver. > Instead of driver, VM would take the responsibility. > > You mean althgouth VM could take the responsiblity, it is hard to > expect amout of pages needed by block drivers? Correct, its near impossible for the VM to accurately guess the amount of memory needed for a driver, or limit the usage of the driver. The driver could be very simple in that it'll just start a DMA on the page and get an interrupt when done, not consuming much (if any) memory beyond the generic BIO structure, but it could also be some iSCSI monstrosity which involves the full network stack and userspace. That is why I generally prefer the user of PF_MEMALLOC to take responsibility, because it knows its own consumption and can limit its own consumption. Now, I don't think (but I could be wring here) that you need to bother with PF_MEMALLOC unless you're swapping. File based pages should always be able to free some memory due to the dirty-limit, whcih basically guarantees that there are some clean file pages for every dirty file page. My swap-over-nfs series used to have a block-layer hook to expose the swap-over-block behaviour: http://programming.kicks-ass.net/kernel-patches/vm_deadlock/v12.99/blk_queue_swapdev.patch That gives block devices the power to refuse being swapped over, which could be an alternative to using PF_MEMALLOC. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
