Hi, Peter. First of all, Thanks for the commenting. On Wed, Nov 18, 2009 at 5:47 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > On Tue, 2009-11-17 at 21:51 +0900, Minchan Kim wrote: >> I think it's because mempool reserves memory. >> (# of I/O issue\0 is hard to be expected. >> How do we determine mempool size of each block driver? >> For example, maybe, server use few I/O for nand. >> but embedded system uses a lot of I/O. > > No, you scale the mempool to the minimum amount required to make > progress -- this includes limiting the 'concurrency' when handing out > mempool objects. > > If you run into such tight corners often enough to notice it, there's > something else wrong. > > I fully agree with ripping out PF_MEMALLOC from pretty much everything, > including the VM, getting rid of the various abuse outside of the VM > seems like a very good start. > I am not against removing PF_MEMALLOC. Totally, I agree to prevent abusing of PF_MEMALLOC. What I have a concern is per-block mempool. Although it's minimum amount of mempool, it can be increased by adding new block driver. I am not sure how many we will have block driver. And, person who develop new driver always have to use mempool and consider what is minimum of mempool. I think this is a problem of mempool, now. How about this? According to system memory, kernel have just one mempool for I/O which is one shared by several block driver. And we make new API block driver can use. Of course, as usual It can use dynamic memoy. Only it can use mempool if system don't have much dynamic memory. In this case, we can control read/write path. read I/O can't help memory reclaiming. So I think read I/O don't use mempool, I am not sure. :) -- Kind regards, Minchan Kim -- 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
