diff for duplicates of <1465332209.22178.236.camel@linux.intel.com> diff --git a/a/1.txt b/N1/1.txt index a8fcb64..8ff25ed 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -3,7 +3,7 @@ On Tue, 2016-06-07 at 17:21 +0900, Minchan Kim wrote: > > > > On Wed, 2016-06-01 at 16:12 +0900, Minchan Kim wrote: > > > -> > > A +> > > > > > Hi Tim, > > > > > > To me, this reorganization is too limited and not good for me, @@ -16,9 +16,9 @@ On Tue, 2016-06-07 at 17:21 +0900, Minchan Kim wrote: > > > help system performance) if batch pages has same inode or anon. > > 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. A 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. A Doing this efficiently is non-trivial. A +> > 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 > from different inode, we can drop the lock and get new lock from new @@ -27,7 +27,7 @@ On Tue, 2016-06-07 at 17:21 +0900, Minchan Kim wrote: Sounds reasonable. But your process function passed to spl_batch_pages may need to be modified to know if the radix tree lock or swap info lock -has already been held, as it deals with only 1 page. A It may be +has already been held, as it deals with only 1 page. It may be tricky as the lock may get acquired and dropped more than once in process function. @@ -41,30 +41,24 @@ Tim > > > > 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. A 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. A Then the lock batching can be implemented -> > for the pages. A 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. A 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. A 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 1dd7f7d..6734f1d 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -26,7 +26,7 @@ "> > \n" "> > On Wed, 2016-06-01 at 16:12 +0900, Minchan Kim wrote:\n" "> > > \n" - "> > > A \n" + "> > > \302\240\n" "> > > Hi Tim,\n" "> > > \n" "> > > To me, this reorganization is too limited and not good for me,\n" @@ -39,9 +39,9 @@ "> > > help system performance) if batch pages has same inode or anon.\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. A 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. A Doing this efficiently is non-trivial. A \n" + "> > acquisition. \302\240Doing this efficiently is non-trivial. \302\240\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" "> from different inode, we can drop the lock and get new lock from new\n" @@ -50,7 +50,7 @@ "\n" "Sounds reasonable. But your process function passed to spl_batch_pages may\n" "need to be modified to know if the radix tree lock or swap info lock\n" - "has already been held, as it deals with only 1 page. A It may be\n" + "has already been held, as it deals with only 1 page. \302\240It may be\n" "tricky as the lock may get acquired and dropped more than once in process\n" "function.\n" "\n" @@ -64,32 +64,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. A 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. A Then the lock batching can be implemented\n" - "> > for the pages. A 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. A 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" "> 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" "> > \n" - "> > neat. A 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 -ae08f95706aa67cf59a53b586ca12eab1c113b921f0055b9bb21323435213abe +0d22a4de293cb304385d1ea1aa135e15930741fd5f373503357a38e796def696
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.