diff for duplicates of <1471454696.2888.94.camel@linux.intel.com> diff --git a/a/1.txt b/N1/1.txt index 6d5126e..bc8093a 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,10 +1,10 @@ On Wed, 2016-08-17 at 14:07 +0900, Minchan Kim wrote: > On Tue, Aug 16, 2016 at 07:06:00PM -0700, Huang, Ying wrote: > > -> >A +> > > > > > > > I think Tim and me discussed about that a few weeks ago. -> > I work closely with Tim on swap optimization.A A This patchset is the part +> > I work closely with Tim on swap optimization. This patchset is the part > > of our swap optimization plan. > > > > > @@ -16,7 +16,7 @@ On Wed, 2016-08-17 at 14:07 +0900, Minchan Kim wrote: > > > It's different with yours which focused on THP swapping while the suggestion > > > would be more general if we can do so it's worth to try it, I think. > > I think the general optimization above will benefit both normal pages -> > and THP at least for now.A A And I think there are no hard conflict +> > and THP at least for now. And I think there are no hard conflict > > between those two patchsets. > If we could do general optimzation, I guess THP swap without splitting > would be more straight forward. @@ -30,10 +30,10 @@ On Wed, 2016-08-17 at 14:07 +0900, Minchan Kim wrote: > > > > > > The THP swap has more opportunity to be optimized, because we can batch -> > 512 operations together more easily.A A For full THP swap support, unmap a +> > 512 operations together more easily. For full THP swap support, unmap a > > THP could be more efficient with only one swap count operation instead > > of 512, so do many other operations, such as add/remove from swap cache -> > with multi-order radix tree etc.A A And it will help memory fragmentation. +> > with multi-order radix tree etc. And it will help memory fragmentation. > > THP can be kept after swapping out/in, need not to rebuild THP via > > khugepaged. > It seems you increased cluster size to 512 and search a empty cluster @@ -46,8 +46,8 @@ On Wed, 2016-08-17 at 14:07 +0900, Minchan Kim wrote: > A : Allocated slot > F : Free slot > -> cluster AA A A cluster B -> AAAAFFFFA A -A A FFFFAAAA +> cluster A cluster B +> AAAAFFFF - FFFFAAAA > > That's one of the reason I suggested batch reclaim work first and > support THP swap based on it. With that, scan_swap_map can be aware of nr_pages @@ -61,15 +61,15 @@ On Wed, 2016-08-17 at 14:07 +0900, Minchan Kim wrote: Minchan, Scanning for contiguous slots that span clusters may take quite a -long time under fragmentation, and may eventually fail. A In that case the addition scan +long time under fragmentation, and may eventually fail. In that case the addition scan time overhead may go to waste and defeat the purpose of fast swapping of large page. The empty cluster lookup on the other hand is very fast. We treat the empty cluster available case as an opportunity for fast path -swap out of large page. A Otherwise, we'll revert to the current +swap out of large page. Otherwise, we'll revert to the current slow path behavior of breaking into normal pages so there's no -regression, and we may get speed up. A We can be considerably faster when a lot of large -pages are used. A +regression, and we may get speed up. We can be considerably faster when a lot of large +pages are used. > @@ -80,18 +80,12 @@ pages are used. A > > Yes, optimizing the normal swap pages is still an important goal -for us. A THP swap optimization is complementary component. A +for us. THP swap optimization is complementary component. We have seen system with THP spend significant cpu cycles breaking up the pages on swap out and then compacting the pages for THP again after -swap in. A So if we can avoid this, that will be helpful. +swap in. So if we can avoid this, that will be helpful. Thanks for your valuable comments. Tim - --- -To unsubscribe, send a message with 'unsubscribe linux-mm' in -the body to majordomo@kvack.org. For more info on Linux MM, -see: http://www.linux-mm.org/ . -Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N1/content_digest index a027bb8..523610c 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -22,10 +22,10 @@ "On Wed, 2016-08-17 at 14:07 +0900, Minchan Kim wrote:\n" "> On Tue, Aug 16, 2016 at 07:06:00PM -0700, Huang, Ying wrote:\n" "> > \n" - "> >A \n" + "> >\302\240\n" "> > > \n" "> > > I think Tim and me discussed about that a few weeks ago.\n" - "> > I work closely with Tim on swap optimization.A A This patchset is the part\n" + "> > I work closely with Tim on swap optimization.\302\240\302\240This patchset is the part\n" "> > of our swap optimization plan.\n" "> > \n" "> > > \n" @@ -37,7 +37,7 @@ "> > > It's different with yours which focused on THP swapping while the suggestion\n" "> > > would be more general if we can do so it's worth to try it, I think.\n" "> > I think the general optimization above will benefit both normal pages\n" - "> > and THP at least for now.A A And I think there are no hard conflict\n" + "> > and THP at least for now.\302\240\302\240And I think there are no hard conflict\n" "> > between those two patchsets.\n" "> If we could do general optimzation, I guess THP swap without splitting\n" "> would be more straight forward.\n" @@ -51,10 +51,10 @@ "> > \n" "> > \n" "> > The THP swap has more opportunity to be optimized, because we can batch\n" - "> > 512 operations together more easily.A A For full THP swap support, unmap a\n" + "> > 512 operations together more easily.\302\240\302\240For full THP swap support, unmap a\n" "> > THP could be more efficient with only one swap count operation instead\n" "> > of 512, so do many other operations, such as add/remove from swap cache\n" - "> > with multi-order radix tree etc.A A And it will help memory fragmentation.\n" + "> > with multi-order radix tree etc.\302\240\302\240And it will help memory fragmentation.\n" "> > THP can be kept after swapping out/in, need not to rebuild THP via\n" "> > khugepaged.\n" "> It seems you increased cluster size to 512 and search a empty cluster\n" @@ -67,8 +67,8 @@ "> A : Allocated slot\n" "> F : Free slot\n" "> \n" - "> cluster AA A A cluster B\n" - "> AAAAFFFFA A -A A FFFFAAAA\n" + "> cluster A\302\240\302\240\302\240cluster B\n" + "> AAAAFFFF\302\240\302\240-\302\240\302\240FFFFAAAA\n" "> \n" "> That's one of the reason I suggested batch reclaim work first and\n" "> support THP swap based on it. With that, scan_swap_map can be aware of nr_pages\n" @@ -82,15 +82,15 @@ "Minchan,\n" "\n" "Scanning for contiguous slots that span clusters may take quite a\n" - "long time under fragmentation, and may eventually fail. A In that case the addition scan\n" + "long time under fragmentation, and may eventually fail. \302\240In that case the addition scan\n" "time overhead may go to waste and defeat the purpose of fast swapping of large page.\n" "\n" "The empty cluster lookup on the other hand is very fast.\n" "We treat the empty cluster available case as an opportunity for fast path\n" - "swap out of large page. A Otherwise, we'll revert to the current\n" + "swap out of large page. \302\240Otherwise, we'll revert to the current\n" "slow path behavior of breaking into normal pages so there's no\n" - "regression, and we may get speed up. A We can be considerably faster when a lot of large\n" - "pages are used. A \n" + "regression, and we may get speed up. \302\240We can be considerably faster when a lot of large\n" + "pages are used. \302\240\n" "\n" "\n" "> \n" @@ -101,20 +101,14 @@ "> > \n" "\n" "Yes, optimizing the normal swap pages is still an important goal\n" - "for us. A THP swap optimization is complementary component. A \n" + "for us. \302\240THP swap optimization is complementary component. \302\240\n" "\n" "We have seen system with THP spend significant cpu cycles breaking up the\n" "pages on swap out and then compacting the pages for THP again after\n" - "swap in. A So if we can avoid this, that will be helpful.\n" + "swap in. \302\240So if we can avoid this, that will be helpful.\n" "\n" "Thanks for your valuable comments.\n" "\n" - "Tim\n" - "\n" - "--\n" - "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" - "the body to majordomo@kvack.org. For more info on Linux MM,\n" - "see: http://www.linux-mm.org/ .\n" - "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" + Tim -be1218aac40ec1225d759d5a1e2e072e058cb1039631cf1aa643d056b6714170 +badf54723261e23c494efa0f32fcee669951dee20108fdfc2a2477fd46f610fd
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.