On Tue 31-07-12 13:32:36, Shawn Joo wrote: > Thank you for attention and comment, here is following question. > > > > 1. In general if order 3(32KB) is required to be allocated, if > "size-32768" cache does not have available slab, then "size-32768" > will request memory from buddy Here watermark is involved as important > factor. > > (I would like to know how to increase the number of object on the > cache, because when cache is created by "kmem_cache_create", there is > only object size, but no number of the object) I am not familiar with the slab allocator much but I do not think this is possible. At least slab drops unused objects if the system is under memory pressure so I do not see how this would help. I guess the problem is the high order allocation itself (maybe you should consider disable jumbo frames?) > > ð my understanding is correct?, please correct. > > 2. In my init.rc, min_free_order_shift is set to 4. I am not familiar with such a tunable. Google says it might be something android specific (https://dev.openwrt.org/browser/trunk/target/linux/goldfish/patches-2.6.30/0055-mm-Add-min_free_order_shift-tunable.patch?rev=16459) > If I decrease this value, it should be helpful. No, quite opposite. From the quick glance at the patch it makes the rules for high order balancing in __zone_watermark_ok more relaxed. min_free_order_shift == 1 is what we do in the upstream kernel. Anyway this will not help much if these allocations are continuous. It would just get the system under a bigger memory pressure because it allows to allocate more memory. > > any recommend size of "min_free_order_shift"? If I can have doc about > it, it will be helpful. You have to ask the patch author for that. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>