On Thu, 12 Jan 2017 09:47:51 +0800 "Huang\, Ying" <ying.huang@xxxxxxxxx> wrote: > >> > 1MB swap space, so for 1TB swap space, the total size will be 80M > >> > compared with 8M of current implementation. > > > > Where did this 80 bytes come from? That swap_cluster_info is 12 bytes > > and could perhaps be squeezed into 8 bytes if we can get away with a > > 24-bit "count". > > Sorry, I made a mistake when measuring the size of swap_cluster_info > when I sent that email, because I turned on the lockdep when measuring. > I have sent out a correction email to Jonathan when I realized that > later. > > So the latest size measuring result is: > > If we use bit_spin_lock, the size of cluster_swap_info will, > > - increased from 4 bytes to 8 bytes on 64 bit platform > - keep as 4 bytes on 32 bit platform > > If we use normal spinlock (queue spinlock), the size of cluster_swap_info will, > > - increased from 4 bytes to 8 bytes on 64 bit platform > - increased from 4 bytes to 8 bytes on 32 bit platform > > So the difference occurs on 32 bit platform. If the size increment on > 32 bit platform is OK, then I think it should be good to use normal > spinlock instead of bit_spin_lock. Personally, I am OK for that. But I > don't know whether there will be some embedded world people don't like > it. I think that'll be OK - the difference is small and many small systems disable swap anyway. So can we please try that? Please do describe the additional overhead (with numbers) in the changelog: "additional bytes of RAM per GB of swap", for example. And please also rerun the performance tests, see if we can notice the alleged speed improvements from switching to a spinlock. -- 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>