diff for duplicates of <20160818083955.GA12296@bbox> diff --git a/a/1.txt b/N1/1.txt index aa1537b..d57d43b 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -4,10 +4,10 @@ On Wed, Aug 17, 2016 at 10:24:56AM -0700, Tim Chen wrote: > 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: > > > -> > > +> > > > > > > > > > > I think Tim and me discussed about that a few weeks ago. -> > > I work closely with Tim on swap optimization. This patchset is the part +> > > I work closely with Tim on swap optimization. This patchset is the part > > > of our swap optimization plan. > > > > > > > @@ -19,7 +19,7 @@ On Wed, Aug 17, 2016 at 10:24:56AM -0700, Tim Chen 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. 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. @@ -33,10 +33,10 @@ On Wed, Aug 17, 2016 at 10:24:56AM -0700, Tim Chen wrote: > > > > > > > > > The THP swap has more opportunity to be optimized, because we can batch -> > > 512 operations together more easily. 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. 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 @@ -49,8 +49,8 @@ On Wed, Aug 17, 2016 at 10:24:56AM -0700, Tim Chen wrote: > > A : Allocated slot > > F : Free slot > > -> > cluster A cluster B -> > AAAAFFFF - 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 @@ -64,15 +64,15 @@ On Wed, Aug 17, 2016 at 10:24:56AM -0700, Tim Chen wrote: > Minchan, > > Scanning for contiguous slots that span clusters may take quite a -> long time under fragmentation, and may eventually fail. 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. 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. We can be considerably faster when a lot of large -> pages are used. +> regression, and we may get speed up. We can be considerably faster when a lot of large +> pages are used. I didn't mean we should search scan_swap_map firstly without peeking free cluster but what I wanted was we might abstract it into @@ -104,18 +104,12 @@ Thanks. > > > > > Yes, optimizing the normal swap pages is still an important goal -> for us. THP swap optimization is complementary component. +> 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. 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. Thanks for good works. - --- -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 a91880a..3eaedc3 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -26,10 +26,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" - "> > > \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. 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" @@ -41,7 +41,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. 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" @@ -55,10 +55,10 @@ "> > > \n" "> > > \n" "> > > The THP swap has more opportunity to be optimized, because we can batch\n" - "> > > 512 operations together more easily. 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. 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" @@ -71,8 +71,8 @@ "> > A : Allocated slot\n" "> > F : Free slot\n" "> > \n" - "> > cluster A cluster B\n" - "> > AAAAFFFF - 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" @@ -86,15 +86,15 @@ "> Minchan,\n" "> \n" "> Scanning for contiguous slots that span clusters may take quite a\n" - "> long time under fragmentation, and may eventually fail. 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. 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. We can be considerably faster when a lot of large\n" - "> pages are used. \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" "I didn't mean we should search scan_swap_map firstly without peeking\n" "free cluster but what I wanted was we might abstract it into\n" @@ -126,20 +126,14 @@ "> > > \n" "> \n" "> Yes, optimizing the normal swap pages is still an important goal\n" - "> for us. THP swap optimization is complementary component. \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. 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" - "Thanks for good works.\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>" + Thanks for good works. -6327b34f283c641429be6c8c8fcd2fdb238ad5869effa65cfd7d1192acac2412 +a977bc8f56d527c11a6237e98f4c08571a79d00a6f81d0c01e1b289dd980b220
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.