Andrew Morton <a...@linux-foundation.org> writes: > On Thu, 12 Jan 2017 09:47:51 +0800 "Huang\, Ying" <ying.hu...@intel.com> > 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.
Sure. I will change it and redo the test. Best Regards, Huang, Ying
