On Wed, 2009-11-18 at 09:01 +0900, Minchan Kim wrote: > 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. :) 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. Current PF_MEMALLOC usage in the VM is utterly broken in that we can have a basically unlimited amount of tasks hit direct reclaim and all of them will then consume PF_MEMALLOC, which mean we can easily run out of memory. ( unless I missed the direct reclaim throttle patches going in, which isn't at all impossible ) -- 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
