On Wed, 30 Jan 2013, Shaohua Li wrote: > On Sun, Jan 27, 2013 at 01:40:40PM -0800, Hugh Dickins wrote: > > > > I'm glad Minchan has now pointed you to Rik's posting of two years ago: > > I think there are more important changes to be made in that direction. > > Not sure how others use multiple swaps, but current lock contention forces us > to use multiple swaps. I haven't carefully think about Rik's posting, but > looks > it doesn't solve the lock contention problem.
Nobody had reported any swap lock contention problem before your patch, so no, Rik's posting wasn't directed at that. I always thought swap writing patterns a much bigger problem. But if lock contention there is, then I think it can be implemented with reducing that in mind. There are two levels of allocation: one to allocate the tokens which we will insert in page tables, and one to allocate the final diskspace to which those tokens will point. (I may be using totally different language from Rik, it's the principles that I have in mind, not his actual posting.) Allocating the tokens can very well be done with per-cpu batches, perhaps of SWAP_CLUSTER_MAX 32 to match vmscan.c's batching: there is no significance to their ordering. And allocating the diskspace would want to be done in batches, to maximize contiguous writing. That may not solve all the swap_info_get() contention which you saw, but should help some. I'm thinking that we go with your per-swapper-space locking for now; but I wouldn't mind taking it out again later, if we arrive at a better solution which benefits even those with a single swap area. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
