diff for duplicates of <1493049811.3209.61.camel@linux.intel.com> diff --git a/a/1.txt b/N1/1.txt index 9e7b95f..c964280 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -26,13 +26,13 @@ On Sun, 2017-04-23 at 21:16 +0800, Huang, Ying wrote: > > > > > > > > > > > > > > > > From: Huang Ying <ying.huang@intel.com> > > > > > > > > -> > > > > > > > A void swapcache_free_entries(swp_entry_t *entries, int n) -> > > > > > > > A { -> > > > > > > > A struct swap_info_struct *p, *prev; +> > > > > > > > void swapcache_free_entries(swp_entry_t *entries, int n) +> > > > > > > > { +> > > > > > > > struct swap_info_struct *p, *prev; > > > > > > > > @@ -1075,6 +1083,10 @@ void swapcache_free_entries(swp_entry_t *entries, int n) -> > > > > > > > A -> > > > > > > > A prev = NULL; -> > > > > > > > A p = NULL; +> > > > > > > > +> > > > > > > > prev = NULL; +> > > > > > > > p = NULL; > > > > > > > > + > > > > > > > > + /* Sort swap entries by swap device, so each lock is only taken once. */ > > > > > > > > + if (nr_swapfiles > 1) @@ -49,7 +49,7 @@ On Sun, 2017-04-23 at 21:16 +0800, Huang, Ying wrote: > > > > > > > > > > > > > > How about lazy sorting approach? IOW, if we found prev != p and, > > > > > > > then we can sort it. -> > > > > > Yes.A A That should be better.A A I just don't know whether the added +> > > > > > Yes. That should be better. I just don't know whether the added > > > > > > complexity is necessary, given the array is short and sort is fast. > > > > > Huh? > > > > > @@ -58,33 +58,25 @@ On Sun, 2017-04-23 at 21:16 +0800, Huang, Ying wrote: > > > > > 3. swapoff /dev/XXX2 > > > > > 4. use only one swap > > > > > 5. then, always pointless sort. -> > > > Yes.A A In this situation we will do unnecessary sorting.A A What I don't +> > > > Yes. In this situation we will do unnecessary sorting. What I don't > > > > know is whether the unnecessary sorting will hurt performance in real -> > > > life.A A I can do some measurement. +> > > > life. I can do some measurement. > > > I tested the patch with 1 swap device and 1 process to eat memory -> > > (remove the "if (nr_swapfiles > 1)" for test).A A +> > > (remove the "if (nr_swapfiles > 1)" for test). > > It is possible that nr_swapfiles > 1 when we have only 1 swapfile due -> > to swapoff. A The nr_swapfiles never decrement on swapoff. +> > to swapoff. The nr_swapfiles never decrement on swapoff. > > We will need to use another counter in alloc_swap_info and > > swapoff to track the true number of swapfiles in use to have a fast path > > that avoid the search and sort for the 1 swap case. -> Yes.A A That is a possible optimization.A A But it doesn't cover another use -> cases raised by Minchan (two swap device with different priority).A A So +> Yes. That is a possible optimization. But it doesn't cover another use +> cases raised by Minchan (two swap device with different priority). So > in general, we still need to check whether there are entries from -> multiple swap devices in the array.A A Given the cost of the checking code +> multiple swap devices in the array. Given the cost of the checking code > is really low, I think maybe we can just always use the checking code. > Do you think so? The single swap case is very common. It will be better if we can bypass the -extra logic and cost for multiple swap. A Yes, we still need the proper +extra logic and cost for multiple swap. Yes, we still need the proper check to see if sort is necessary as you proposed for the multiple swap case. 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 40c797d..391dc09 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -48,13 +48,13 @@ "> > > > > > > > \n" "> > > > > > > > From: Huang Ying <ying.huang@intel.com>\n" "> > > > > > > > \n" - "> > > > > > > > A void swapcache_free_entries(swp_entry_t *entries, int n)\n" - "> > > > > > > > A {\n" - "> > > > > > > > A \tstruct swap_info_struct *p, *prev;\n" + "> > > > > > > > \302\240void swapcache_free_entries(swp_entry_t *entries, int n)\n" + "> > > > > > > > \302\240{\n" + "> > > > > > > > \302\240\tstruct swap_info_struct *p, *prev;\n" "> > > > > > > > @@ -1075,6 +1083,10 @@ void swapcache_free_entries(swp_entry_t *entries, int n)\n" - "> > > > > > > > A \n" - "> > > > > > > > A \tprev = NULL;\n" - "> > > > > > > > A \tp = NULL;\n" + "> > > > > > > > \302\240\n" + "> > > > > > > > \302\240\tprev = NULL;\n" + "> > > > > > > > \302\240\tp = NULL;\n" "> > > > > > > > +\n" "> > > > > > > > +\t/* Sort swap entries by swap device, so each lock is only taken once. */\n" "> > > > > > > > +\tif (nr_swapfiles > 1)\n" @@ -71,7 +71,7 @@ "> > > > > > > \n" "> > > > > > > How about lazy sorting approach? IOW, if we found prev != p and,\n" "> > > > > > > then we can sort it.\n" - "> > > > > > Yes.A A That should be better.A A I just don't know whether the added\n" + "> > > > > > Yes.\302\240\302\240That should be better.\302\240\302\240I just don't know whether the added\n" "> > > > > > complexity is necessary, given the array is short and sort is fast.\n" "> > > > > Huh?\n" "> > > > > \n" @@ -80,35 +80,27 @@ "> > > > > 3. swapoff /dev/XXX2\n" "> > > > > 4. use only one swap\n" "> > > > > 5. then, always pointless sort.\n" - "> > > > Yes.A A In this situation we will do unnecessary sorting.A A What I don't\n" + "> > > > Yes.\302\240\302\240In this situation we will do unnecessary sorting.\302\240\302\240What I don't\n" "> > > > know is whether the unnecessary sorting will hurt performance in real\n" - "> > > > life.A A I can do some measurement.\n" + "> > > > life.\302\240\302\240I can do some measurement.\n" "> > > I tested the patch with 1 swap device and 1 process to eat memory\n" - "> > > (remove the \"if (nr_swapfiles > 1)\" for test).A A \n" + "> > > (remove the \"if (nr_swapfiles > 1)\" for test).\302\240\302\240\n" "> > It is possible that nr_swapfiles > 1 when we have only 1 swapfile due\n" - "> > to swapoff. A The nr_swapfiles never decrement on swapoff.\n" + "> > to swapoff. \302\240The nr_swapfiles never decrement on swapoff.\n" "> > We will need to use another counter in alloc_swap_info and\n" "> > swapoff to track the true number of swapfiles in use to have a fast path\n" "> > that avoid the search and sort for the 1 swap case.\n" - "> Yes.A A That is a possible optimization.A A But it doesn't cover another use\n" - "> cases raised by Minchan (two swap device with different priority).A A So\n" + "> Yes.\302\240\302\240That is a possible optimization.\302\240\302\240But it doesn't cover another use\n" + "> cases raised by Minchan (two swap device with different priority).\302\240\302\240So\n" "> in general, we still need to check whether there are entries from\n" - "> multiple swap devices in the array.A A Given the cost of the checking code\n" + "> multiple swap devices in the array.\302\240\302\240Given the cost of the checking code\n" "> is really low, I think maybe we can just always use the checking code.\n" "> Do you think so?\n" "\n" "The single swap case is very common. It will be better if we can bypass the\n" - "extra logic and cost for multiple swap. A Yes, we still need the proper\n" + "extra logic and cost for multiple swap. \302\240Yes, we still need the proper\n" "check to see if sort is necessary as you proposed for the multiple swap case.\n" "\n" - "Tim\n" - "\n" - "\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 -e3902e13aa41ab47159fee8d0b70e566581125b1c762b36346ad849ad57a4c92 +5d5c14bfe95312f268fbb19f9aa54dab54c48d3160b22e55ccbc70565221c0a6
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.