On Mon 18-08-14 13:44:38, Gioh Kim wrote: > > > 2014-08-18 오후 12:24, Theodore Ts'o 쓴 글: > >On Mon, Aug 18, 2014 at 10:15:32AM +0900, Gioh Kim wrote: > >> > >>My test platform has totally 1GB memory, 256MB for CMA and 768MB for normal. > >>I applied Joonsoo's patch: https://lkml.org/lkml/2014/5/28/64, so that > >>3/4 of allocation take place in normal area and 1/4 allocation take place in CMA area. > >> > >>And my platform has 4 ext4 partitions. Each ext4 partition has 2 page caches for superblock that > >>are what this patch tries to move to out of CMA area. > >>Therefore there are 8 page caches (8 pages size) that can prevent page migration. > > > >Yes, but are you actually *using* the ext4 partitions for anything? > >If this is a realistic real world use case, file systems are used to > >store, well, files, and that means there will be inodes and dentry > >cache entries that will also be allocated. Does your test scenario > >reflect real world usage? > > Yes. I'm working for LG Electronics. > My test platform is currently selling item in the market. > And also I test my patch when my platform is working as if real user uses it. Great, this is exactly what I was looking for. So if it really makes your usecase work I don't have objections to your solution (after you change what Andrew suggested). > I think the page caches of the inodes and dentry are held for short time. > I can see pairs of get_bh and put_bh in inodes/dentry handling. > > I think inodes is allocated by kmem_cache_alloc in ext4_alloc_inode(). > It is non-movable area allocation. I guess the hold time depends on what storage do you use in your product (flash?) and how loaded it is. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- 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
