diff for duplicates of <20160607082158.GA23435@bbox> diff --git a/a/1.txt b/N1/1.txt index 37ae583..33b0fb6 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,6 +1,6 @@ On Wed, Jun 01, 2016 at 11:23:53AM -0700, Tim Chen wrote: > On Wed, 2016-06-01 at 16:12 +0900, Minchan Kim wrote: -> > +> > > > Hi Tim, > > > > To me, this reorganization is too limited and not good for me, @@ -14,9 +14,9 @@ On Wed, Jun 01, 2016 at 11:23:53AM -0700, Tim Chen wrote: > > This is also my goal to group pages that are either under the same > mapping or are anonymous pages together so we can reduce the i_mmap_lock -> acquisition. One logic that's yet to be implemented in your patch +> acquisition. One logic that's yet to be implemented in your patch > is the grouping of similar pages together so we only need one i_mmap_lock -> acquisition. Doing this efficiently is non-trivial. +> acquisition. Doing this efficiently is non-trivial. Hmm, my assumption is based on same inode pages are likely to order in LRU so no need to group them. If successive page in page_list comes @@ -26,30 +26,24 @@ inode. That sounds strange? > > I punted the problem somewhat in my patch and elected to defer the processing > of the anonymous pages at the end so they are naturally grouped without -> having to traverse the page_list more than once. So I'm batching the +> having to traverse the page_list more than once. So I'm batching the > anonymous pages but the file mapped pages were not grouped. > > In your implementation, you may need to traverse the page_list in two pass, where the > first one is to categorize the pages and grouping them and the second one -> is the actual processing. Then the lock batching can be implemented -> for the pages. Otherwise the locking is still done page by page in +> is the actual processing. Then the lock batching can be implemented +> for the pages. Otherwise the locking is still done page by page in > your patch, and can only be batched if the next page on page_list happens -> to have the same mapping. Your idea of using a spl_batch_pages is pretty +> to have the same mapping. Your idea of using a spl_batch_pages is pretty Yes. as I said above, I expect pages in LRU would be likely to order per inode normally. If it's not, yeb, we need grouping but such overhead would mitigate the benefit of lock batch as SWAP_CLUSTER_MAX get bigger. -> neat. It may need some enhancement so it is known whether some locks +> neat. It may need some enhancement so it is known whether some locks > are already held for lock batching purpose. > > > Thanks. > > 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 630d6c8..1c13e55 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -22,7 +22,7 @@ "b\0" "On Wed, Jun 01, 2016 at 11:23:53AM -0700, Tim Chen wrote:\n" "> On Wed, 2016-06-01 at 16:12 +0900, Minchan Kim wrote:\n" - "> > \n" + "> >\302\240\n" "> > Hi Tim,\n" "> > \n" "> > To me, this reorganization is too limited and not good for me,\n" @@ -36,9 +36,9 @@ "> \n" "> This is also my goal to group pages that are either under the same\n" "> mapping or are anonymous pages together so we can reduce the i_mmap_lock\n" - "> acquisition. One logic that's yet to be implemented in your patch\n" + "> acquisition. \302\240One logic that's yet to be implemented in your patch\n" "> is the grouping of similar pages together so we only need one i_mmap_lock\n" - "> acquisition. Doing this efficiently is non-trivial. \n" + "> acquisition. \302\240Doing this efficiently is non-trivial. \302\240\n" "\n" "Hmm, my assumption is based on same inode pages are likely to order\n" "in LRU so no need to group them. If successive page in page_list comes\n" @@ -48,32 +48,26 @@ "> \n" "> I punted the problem somewhat in my patch and elected to defer the processing\n" "> of the anonymous pages at the end so they are naturally grouped without\n" - "> having to traverse the page_list more than once. So I'm batching the\n" + "> having to traverse the page_list more than once. \302\240So I'm batching the\n" "> anonymous pages but the file mapped pages were not grouped.\n" "> \n" "> In your implementation, you may need to traverse the page_list in two pass, where the\n" "> first one is to categorize the pages and grouping them and the second one\n" - "> is the actual processing. Then the lock batching can be implemented\n" - "> for the pages. Otherwise the locking is still done page by page in\n" + "> is the actual processing. \302\240Then the lock batching can be implemented\n" + "> for the pages. \302\240Otherwise the locking is still done page by page in\n" "> your patch, and can only be batched if the next page on page_list happens\n" - "> to have the same mapping. Your idea of using a spl_batch_pages is pretty\n" + "> to have the same mapping. \302\240Your idea of using a spl_batch_pages is pretty\n" "\n" "Yes. as I said above, I expect pages in LRU would be likely to order per\n" "inode normally. If it's not, yeb, we need grouping but such overhead would\n" "mitigate the benefit of lock batch as SWAP_CLUSTER_MAX get bigger.\n" "\n" - "> neat. It may need some enhancement so it is known whether some locks\n" + "> neat. \302\240It may need some enhancement so it is known whether some locks\n" "> are already held for lock batching purpose.\n" "> \n" "> \n" "> Thanks.\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 -ca9068112c565b8f5b059d9dc081afd47b54290502c96077d9c793248c76d8ff +3ae6250464b76272fba7ac2f4ffe89455059a188e6d0868b8f3743d4d5de231b
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.