On Thu, Oct 25, 2012 at 09:20:37AM +0900, Minchan Kim wrote: > Hi Shaohua, > > Your idea does make sense to me. > Below just a few nitpick. Thanks for your time. > On Mon, Oct 22, 2012 at 10:30:51AM +0800, Shaohua Li wrote: > > I'm using a fast SSD to do swap. scan_swap_map() sometimes uses up to 20~30% > > CPU time (when cluster is hard to find), which becomes a bottleneck. > > scan_swap_map() scans a byte array to search a 256 page cluster, which is very > > slow. > > > > Here I introduced a simple buddy allocator. Since we only care about 256 pages > > cluster, we can just use a counter to implement the buddy allocator. Every 256 > > pages use one int to store the counter, so searching cluster is very efficient. > > With this, scap_swap_map() overhead disappears. > > > > This might help low end SD card swap too. Because if the cluster is aligned, SD > > firmware can do flash erase more efficiently. > > Indeed. > > > > > The downside is the cluster must be aligned to 256 pages, which will reduce the > > chance to find a cluster. > > It would be not good for roration device. Can't we make it for only discardable > device? This is the biggest concern. Andrew raised it too. If most swap space isn't full, this isn't a problem. Otherwise, might be. But I didn't find a way to evaluate how big the chance is reduced. I can try if anybody has ideal workload. If can't evaluate the chance, I'll choose to only enable it for discardable device. Other comments make sense, I'll update in next post. Thanks, Shaohua -- 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>