Re: [RFC PATCH 0/5] Support multiple pages allocation
On Wed, Jul 10, 2013 at 01:27:37PM +0200, Michal Hocko wrote: > On Wed 10-07-13 18:55:33, Joonsoo Kim wrote: > > On Wed, Jul 10, 2013 at 11:17:03AM +0200, Michal Hocko wrote: > > > On Wed 10-07-13 09:31:42, Joonsoo Kim wrote: > > > > On Thu, Jul 04, 2013 at 12:00:44PM +0200, Michal Hocko wrote: > [...] > > > > > Which benchmark you are using for this testing? > > > > > > > > I use my own module which do allocation repeatedly. > > > > > > I am not sure this microbenchmark will tell us much. Allocations are > > > usually not short lived so the longer time might get amortized. > > > If you want to use the multi page allocation for read ahead then try to > > > model your numbers on read-ahead workloads. > > > > Of couse. In later, I will get the result on read-ahead workloads or > > vmalloc workload which is recommended by Zhang. > > > > I think, without this microbenchmark, we cannot know this modification's > > performance effect to single page allocation accurately. Because the impact > > to single page allocation is relatively small and it is easily hidden by > > other factors. > > The main thing is whether the numbers you get from an artificial > microbenchmark matter at all. You might see a regression which cannot be > hit in practice because other effects are of magnitude more significant. Okay. I will keep this in mind. Thanks for your comment. > -- > Michal Hocko > SUSE Labs > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Support multiple pages allocation
On Wed 10-07-13 18:55:33, Joonsoo Kim wrote: > On Wed, Jul 10, 2013 at 11:17:03AM +0200, Michal Hocko wrote: > > On Wed 10-07-13 09:31:42, Joonsoo Kim wrote: > > > On Thu, Jul 04, 2013 at 12:00:44PM +0200, Michal Hocko wrote: [...] > > > > Which benchmark you are using for this testing? > > > > > > I use my own module which do allocation repeatedly. > > > > I am not sure this microbenchmark will tell us much. Allocations are > > usually not short lived so the longer time might get amortized. > > If you want to use the multi page allocation for read ahead then try to > > model your numbers on read-ahead workloads. > > Of couse. In later, I will get the result on read-ahead workloads or > vmalloc workload which is recommended by Zhang. > > I think, without this microbenchmark, we cannot know this modification's > performance effect to single page allocation accurately. Because the impact > to single page allocation is relatively small and it is easily hidden by > other factors. The main thing is whether the numbers you get from an artificial microbenchmark matter at all. You might see a regression which cannot be hit in practice because other effects are of magnitude more significant. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Support multiple pages allocation
On Wed, Jul 10, 2013 at 09:20:27AM +0800, Zhang Yanfei wrote: > 于 2013/7/10 8:31, Joonsoo Kim 写道: > > On Thu, Jul 04, 2013 at 12:00:44PM +0200, Michal Hocko wrote: > >> On Thu 04-07-13 13:24:50, Joonsoo Kim wrote: > >>> On Thu, Jul 04, 2013 at 12:01:43AM +0800, Zhang Yanfei wrote: > On 07/03/2013 11:51 PM, Zhang Yanfei wrote: > > On 07/03/2013 11:28 PM, Michal Hocko wrote: > >> On Wed 03-07-13 17:34:15, Joonsoo Kim wrote: > >> [...] > >>> For one page allocation at once, this patchset makes allocator slower > >>> than > >>> before (-5%). > >> > >> Slowing down the most used path is a no-go. Where does this slow down > >> come from? > > > > I guess, it might be: for one page allocation at once, comparing to the > > original > > code, this patch adds two parameters nr_pages and pages and will do > > extra checks > > for the parameter nr_pages in the allocation path. > > > > If so, adding a separate path for the multiple allocations seems better. > >>> > >>> Hello, all. > >>> > >>> I modify the code for optimizing one page allocation via likely macro. > >>> I attach a new one at the end of this mail. > >>> > >>> In this case, performance degradation for one page allocation at once is > >>> -2.5%. > >>> I guess, remained overhead comes from two added parameters. > >>> Is it unreasonable cost to support this new feature? > >> > >> Which benchmark you are using for this testing? > > > > I use my own module which do allocation repeatedly. > > > >> > >>> I think that readahead path is one of the most used path, so this penalty > >>> looks > >>> endurable. And after supporting this feature, we can find more use cases. > >> > >> What about page faults? I would oppose that page faults are _much_ more > >> frequent than read ahead so you really cannot slow them down. > > > > You mean page faults for anon? > > Yes. I also think that it is much more frequent than read ahead. > > Before futher discussion, I will try to add a separate path > > for the multiple allocations. > > Some days ago, I was thinking that this multiple allocation behaviour > may be useful for vmalloc allocations. So I think it is worth trying. Yeh! I think so! Thanks. > > > > > Thanks. > > > >> > >> [...] > >> -- > >> Michal Hocko > >> SUSE Labs > >> > >> -- > >> To unsubscribe, send a message with 'unsubscribe linux-mm' in > >> the body to majord...@kvack.org. For more info on Linux MM, > >> see: http://www.linux-mm.org/ . > >> Don't email: mailto:"d...@kvack.org;> em...@kvack.org > > > > > -- > Thanks. > Zhang Yanfei > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Support multiple pages allocation
On Wed, Jul 10, 2013 at 11:17:03AM +0200, Michal Hocko wrote: > On Wed 10-07-13 09:31:42, Joonsoo Kim wrote: > > On Thu, Jul 04, 2013 at 12:00:44PM +0200, Michal Hocko wrote: > > > On Thu 04-07-13 13:24:50, Joonsoo Kim wrote: > > > > On Thu, Jul 04, 2013 at 12:01:43AM +0800, Zhang Yanfei wrote: > > > > > On 07/03/2013 11:51 PM, Zhang Yanfei wrote: > > > > > > On 07/03/2013 11:28 PM, Michal Hocko wrote: > > > > > >> On Wed 03-07-13 17:34:15, Joonsoo Kim wrote: > > > > > >> [...] > > > > > >>> For one page allocation at once, this patchset makes allocator > > > > > >>> slower than > > > > > >>> before (-5%). > > > > > >> > > > > > >> Slowing down the most used path is a no-go. Where does this slow > > > > > >> down > > > > > >> come from? > > > > > > > > > > > > I guess, it might be: for one page allocation at once, comparing to > > > > > > the original > > > > > > code, this patch adds two parameters nr_pages and pages and will do > > > > > > extra checks > > > > > > for the parameter nr_pages in the allocation path. > > > > > > > > > > > > > > > > If so, adding a separate path for the multiple allocations seems > > > > > better. > > > > > > > > Hello, all. > > > > > > > > I modify the code for optimizing one page allocation via likely macro. > > > > I attach a new one at the end of this mail. > > > > > > > > In this case, performance degradation for one page allocation at once > > > > is -2.5%. > > > > I guess, remained overhead comes from two added parameters. > > > > Is it unreasonable cost to support this new feature? > > > > > > Which benchmark you are using for this testing? > > > > I use my own module which do allocation repeatedly. > > I am not sure this microbenchmark will tell us much. Allocations are > usually not short lived so the longer time might get amortized. > If you want to use the multi page allocation for read ahead then try to > model your numbers on read-ahead workloads. Of couse. In later, I will get the result on read-ahead workloads or vmalloc workload which is recommended by Zhang. I think, without this microbenchmark, we cannot know this modification's performance effect to single page allocation accurately. Because the impact to single page allocation is relatively small and it is easily hidden by other factors. Now, I tried several implementation for this feature and found that separate path also makes single page allocation slower (-1.0~-1.5%). I didn't find any reason except the fact that text size of page_alloc.o is 1500 bytes more than before. Before textdata bss dec hex filename 344661389 640 364958e8f mm/page_alloc.o sep textdata bss dec hex filename 360741413 640 3812794ef mm/page_alloc.o Not yet posted implementation which pass two more arguments to __alloc_pages_nodemask() also makes single page allocation (-1.0~-1.5%) slower. So in later, I will work with this implementation, not separate path implementation. Thanks for comment! > -- > Michal Hocko > SUSE Labs > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Support multiple pages allocation
On Wed 10-07-13 09:31:42, Joonsoo Kim wrote: > On Thu, Jul 04, 2013 at 12:00:44PM +0200, Michal Hocko wrote: > > On Thu 04-07-13 13:24:50, Joonsoo Kim wrote: > > > On Thu, Jul 04, 2013 at 12:01:43AM +0800, Zhang Yanfei wrote: > > > > On 07/03/2013 11:51 PM, Zhang Yanfei wrote: > > > > > On 07/03/2013 11:28 PM, Michal Hocko wrote: > > > > >> On Wed 03-07-13 17:34:15, Joonsoo Kim wrote: > > > > >> [...] > > > > >>> For one page allocation at once, this patchset makes allocator > > > > >>> slower than > > > > >>> before (-5%). > > > > >> > > > > >> Slowing down the most used path is a no-go. Where does this slow down > > > > >> come from? > > > > > > > > > > I guess, it might be: for one page allocation at once, comparing to > > > > > the original > > > > > code, this patch adds two parameters nr_pages and pages and will do > > > > > extra checks > > > > > for the parameter nr_pages in the allocation path. > > > > > > > > > > > > > If so, adding a separate path for the multiple allocations seems better. > > > > > > Hello, all. > > > > > > I modify the code for optimizing one page allocation via likely macro. > > > I attach a new one at the end of this mail. > > > > > > In this case, performance degradation for one page allocation at once is > > > -2.5%. > > > I guess, remained overhead comes from two added parameters. > > > Is it unreasonable cost to support this new feature? > > > > Which benchmark you are using for this testing? > > I use my own module which do allocation repeatedly. I am not sure this microbenchmark will tell us much. Allocations are usually not short lived so the longer time might get amortized. If you want to use the multi page allocation for read ahead then try to model your numbers on read-ahead workloads. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Support multiple pages allocation
On Wed 10-07-13 09:31:42, Joonsoo Kim wrote: On Thu, Jul 04, 2013 at 12:00:44PM +0200, Michal Hocko wrote: On Thu 04-07-13 13:24:50, Joonsoo Kim wrote: On Thu, Jul 04, 2013 at 12:01:43AM +0800, Zhang Yanfei wrote: On 07/03/2013 11:51 PM, Zhang Yanfei wrote: On 07/03/2013 11:28 PM, Michal Hocko wrote: On Wed 03-07-13 17:34:15, Joonsoo Kim wrote: [...] For one page allocation at once, this patchset makes allocator slower than before (-5%). Slowing down the most used path is a no-go. Where does this slow down come from? I guess, it might be: for one page allocation at once, comparing to the original code, this patch adds two parameters nr_pages and pages and will do extra checks for the parameter nr_pages in the allocation path. If so, adding a separate path for the multiple allocations seems better. Hello, all. I modify the code for optimizing one page allocation via likely macro. I attach a new one at the end of this mail. In this case, performance degradation for one page allocation at once is -2.5%. I guess, remained overhead comes from two added parameters. Is it unreasonable cost to support this new feature? Which benchmark you are using for this testing? I use my own module which do allocation repeatedly. I am not sure this microbenchmark will tell us much. Allocations are usually not short lived so the longer time might get amortized. If you want to use the multi page allocation for read ahead then try to model your numbers on read-ahead workloads. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Support multiple pages allocation
On Wed, Jul 10, 2013 at 11:17:03AM +0200, Michal Hocko wrote: On Wed 10-07-13 09:31:42, Joonsoo Kim wrote: On Thu, Jul 04, 2013 at 12:00:44PM +0200, Michal Hocko wrote: On Thu 04-07-13 13:24:50, Joonsoo Kim wrote: On Thu, Jul 04, 2013 at 12:01:43AM +0800, Zhang Yanfei wrote: On 07/03/2013 11:51 PM, Zhang Yanfei wrote: On 07/03/2013 11:28 PM, Michal Hocko wrote: On Wed 03-07-13 17:34:15, Joonsoo Kim wrote: [...] For one page allocation at once, this patchset makes allocator slower than before (-5%). Slowing down the most used path is a no-go. Where does this slow down come from? I guess, it might be: for one page allocation at once, comparing to the original code, this patch adds two parameters nr_pages and pages and will do extra checks for the parameter nr_pages in the allocation path. If so, adding a separate path for the multiple allocations seems better. Hello, all. I modify the code for optimizing one page allocation via likely macro. I attach a new one at the end of this mail. In this case, performance degradation for one page allocation at once is -2.5%. I guess, remained overhead comes from two added parameters. Is it unreasonable cost to support this new feature? Which benchmark you are using for this testing? I use my own module which do allocation repeatedly. I am not sure this microbenchmark will tell us much. Allocations are usually not short lived so the longer time might get amortized. If you want to use the multi page allocation for read ahead then try to model your numbers on read-ahead workloads. Of couse. In later, I will get the result on read-ahead workloads or vmalloc workload which is recommended by Zhang. I think, without this microbenchmark, we cannot know this modification's performance effect to single page allocation accurately. Because the impact to single page allocation is relatively small and it is easily hidden by other factors. Now, I tried several implementation for this feature and found that separate path also makes single page allocation slower (-1.0~-1.5%). I didn't find any reason except the fact that text size of page_alloc.o is 1500 bytes more than before. Before textdata bss dec hex filename 344661389 640 364958e8f mm/page_alloc.o sep textdata bss dec hex filename 360741413 640 3812794ef mm/page_alloc.o Not yet posted implementation which pass two more arguments to __alloc_pages_nodemask() also makes single page allocation (-1.0~-1.5%) slower. So in later, I will work with this implementation, not separate path implementation. Thanks for comment! -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Support multiple pages allocation
On Wed, Jul 10, 2013 at 09:20:27AM +0800, Zhang Yanfei wrote: 于 2013/7/10 8:31, Joonsoo Kim 写道: On Thu, Jul 04, 2013 at 12:00:44PM +0200, Michal Hocko wrote: On Thu 04-07-13 13:24:50, Joonsoo Kim wrote: On Thu, Jul 04, 2013 at 12:01:43AM +0800, Zhang Yanfei wrote: On 07/03/2013 11:51 PM, Zhang Yanfei wrote: On 07/03/2013 11:28 PM, Michal Hocko wrote: On Wed 03-07-13 17:34:15, Joonsoo Kim wrote: [...] For one page allocation at once, this patchset makes allocator slower than before (-5%). Slowing down the most used path is a no-go. Where does this slow down come from? I guess, it might be: for one page allocation at once, comparing to the original code, this patch adds two parameters nr_pages and pages and will do extra checks for the parameter nr_pages in the allocation path. If so, adding a separate path for the multiple allocations seems better. Hello, all. I modify the code for optimizing one page allocation via likely macro. I attach a new one at the end of this mail. In this case, performance degradation for one page allocation at once is -2.5%. I guess, remained overhead comes from two added parameters. Is it unreasonable cost to support this new feature? Which benchmark you are using for this testing? I use my own module which do allocation repeatedly. I think that readahead path is one of the most used path, so this penalty looks endurable. And after supporting this feature, we can find more use cases. What about page faults? I would oppose that page faults are _much_ more frequent than read ahead so you really cannot slow them down. You mean page faults for anon? Yes. I also think that it is much more frequent than read ahead. Before futher discussion, I will try to add a separate path for the multiple allocations. Some days ago, I was thinking that this multiple allocation behaviour may be useful for vmalloc allocations. So I think it is worth trying. Yeh! I think so! Thanks. Thanks. [...] -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- Thanks. Zhang Yanfei -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Support multiple pages allocation
On Wed 10-07-13 18:55:33, Joonsoo Kim wrote: On Wed, Jul 10, 2013 at 11:17:03AM +0200, Michal Hocko wrote: On Wed 10-07-13 09:31:42, Joonsoo Kim wrote: On Thu, Jul 04, 2013 at 12:00:44PM +0200, Michal Hocko wrote: [...] Which benchmark you are using for this testing? I use my own module which do allocation repeatedly. I am not sure this microbenchmark will tell us much. Allocations are usually not short lived so the longer time might get amortized. If you want to use the multi page allocation for read ahead then try to model your numbers on read-ahead workloads. Of couse. In later, I will get the result on read-ahead workloads or vmalloc workload which is recommended by Zhang. I think, without this microbenchmark, we cannot know this modification's performance effect to single page allocation accurately. Because the impact to single page allocation is relatively small and it is easily hidden by other factors. The main thing is whether the numbers you get from an artificial microbenchmark matter at all. You might see a regression which cannot be hit in practice because other effects are of magnitude more significant. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Support multiple pages allocation
On Wed, Jul 10, 2013 at 01:27:37PM +0200, Michal Hocko wrote: On Wed 10-07-13 18:55:33, Joonsoo Kim wrote: On Wed, Jul 10, 2013 at 11:17:03AM +0200, Michal Hocko wrote: On Wed 10-07-13 09:31:42, Joonsoo Kim wrote: On Thu, Jul 04, 2013 at 12:00:44PM +0200, Michal Hocko wrote: [...] Which benchmark you are using for this testing? I use my own module which do allocation repeatedly. I am not sure this microbenchmark will tell us much. Allocations are usually not short lived so the longer time might get amortized. If you want to use the multi page allocation for read ahead then try to model your numbers on read-ahead workloads. Of couse. In later, I will get the result on read-ahead workloads or vmalloc workload which is recommended by Zhang. I think, without this microbenchmark, we cannot know this modification's performance effect to single page allocation accurately. Because the impact to single page allocation is relatively small and it is easily hidden by other factors. The main thing is whether the numbers you get from an artificial microbenchmark matter at all. You might see a regression which cannot be hit in practice because other effects are of magnitude more significant. Okay. I will keep this in mind. Thanks for your comment. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Support multiple pages allocation
于 2013/7/10 8:31, Joonsoo Kim 写道: > On Thu, Jul 04, 2013 at 12:00:44PM +0200, Michal Hocko wrote: >> On Thu 04-07-13 13:24:50, Joonsoo Kim wrote: >>> On Thu, Jul 04, 2013 at 12:01:43AM +0800, Zhang Yanfei wrote: On 07/03/2013 11:51 PM, Zhang Yanfei wrote: > On 07/03/2013 11:28 PM, Michal Hocko wrote: >> On Wed 03-07-13 17:34:15, Joonsoo Kim wrote: >> [...] >>> For one page allocation at once, this patchset makes allocator slower >>> than >>> before (-5%). >> >> Slowing down the most used path is a no-go. Where does this slow down >> come from? > > I guess, it might be: for one page allocation at once, comparing to the > original > code, this patch adds two parameters nr_pages and pages and will do extra > checks > for the parameter nr_pages in the allocation path. > If so, adding a separate path for the multiple allocations seems better. >>> >>> Hello, all. >>> >>> I modify the code for optimizing one page allocation via likely macro. >>> I attach a new one at the end of this mail. >>> >>> In this case, performance degradation for one page allocation at once is >>> -2.5%. >>> I guess, remained overhead comes from two added parameters. >>> Is it unreasonable cost to support this new feature? >> >> Which benchmark you are using for this testing? > > I use my own module which do allocation repeatedly. > >> >>> I think that readahead path is one of the most used path, so this penalty >>> looks >>> endurable. And after supporting this feature, we can find more use cases. >> >> What about page faults? I would oppose that page faults are _much_ more >> frequent than read ahead so you really cannot slow them down. > > You mean page faults for anon? > Yes. I also think that it is much more frequent than read ahead. > Before futher discussion, I will try to add a separate path > for the multiple allocations. Some days ago, I was thinking that this multiple allocation behaviour may be useful for vmalloc allocations. So I think it is worth trying. > > Thanks. > >> >> [...] >> -- >> Michal Hocko >> SUSE Labs >> >> -- >> To unsubscribe, send a message with 'unsubscribe linux-mm' in >> the body to majord...@kvack.org. For more info on Linux MM, >> see: http://www.linux-mm.org/ . >> Don't email: mailto:"d...@kvack.org;> em...@kvack.org > -- Thanks. Zhang Yanfei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Support multiple pages allocation
On Thu, Jul 04, 2013 at 12:00:44PM +0200, Michal Hocko wrote: > On Thu 04-07-13 13:24:50, Joonsoo Kim wrote: > > On Thu, Jul 04, 2013 at 12:01:43AM +0800, Zhang Yanfei wrote: > > > On 07/03/2013 11:51 PM, Zhang Yanfei wrote: > > > > On 07/03/2013 11:28 PM, Michal Hocko wrote: > > > >> On Wed 03-07-13 17:34:15, Joonsoo Kim wrote: > > > >> [...] > > > >>> For one page allocation at once, this patchset makes allocator slower > > > >>> than > > > >>> before (-5%). > > > >> > > > >> Slowing down the most used path is a no-go. Where does this slow down > > > >> come from? > > > > > > > > I guess, it might be: for one page allocation at once, comparing to the > > > > original > > > > code, this patch adds two parameters nr_pages and pages and will do > > > > extra checks > > > > for the parameter nr_pages in the allocation path. > > > > > > > > > > If so, adding a separate path for the multiple allocations seems better. > > > > Hello, all. > > > > I modify the code for optimizing one page allocation via likely macro. > > I attach a new one at the end of this mail. > > > > In this case, performance degradation for one page allocation at once is > > -2.5%. > > I guess, remained overhead comes from two added parameters. > > Is it unreasonable cost to support this new feature? > > Which benchmark you are using for this testing? I use my own module which do allocation repeatedly. > > > I think that readahead path is one of the most used path, so this penalty > > looks > > endurable. And after supporting this feature, we can find more use cases. > > What about page faults? I would oppose that page faults are _much_ more > frequent than read ahead so you really cannot slow them down. You mean page faults for anon? Yes. I also think that it is much more frequent than read ahead. Before futher discussion, I will try to add a separate path for the multiple allocations. Thanks. > > [...] > -- > Michal Hocko > SUSE Labs > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Support multiple pages allocation
On Thu, Jul 04, 2013 at 12:00:44PM +0200, Michal Hocko wrote: On Thu 04-07-13 13:24:50, Joonsoo Kim wrote: On Thu, Jul 04, 2013 at 12:01:43AM +0800, Zhang Yanfei wrote: On 07/03/2013 11:51 PM, Zhang Yanfei wrote: On 07/03/2013 11:28 PM, Michal Hocko wrote: On Wed 03-07-13 17:34:15, Joonsoo Kim wrote: [...] For one page allocation at once, this patchset makes allocator slower than before (-5%). Slowing down the most used path is a no-go. Where does this slow down come from? I guess, it might be: for one page allocation at once, comparing to the original code, this patch adds two parameters nr_pages and pages and will do extra checks for the parameter nr_pages in the allocation path. If so, adding a separate path for the multiple allocations seems better. Hello, all. I modify the code for optimizing one page allocation via likely macro. I attach a new one at the end of this mail. In this case, performance degradation for one page allocation at once is -2.5%. I guess, remained overhead comes from two added parameters. Is it unreasonable cost to support this new feature? Which benchmark you are using for this testing? I use my own module which do allocation repeatedly. I think that readahead path is one of the most used path, so this penalty looks endurable. And after supporting this feature, we can find more use cases. What about page faults? I would oppose that page faults are _much_ more frequent than read ahead so you really cannot slow them down. You mean page faults for anon? Yes. I also think that it is much more frequent than read ahead. Before futher discussion, I will try to add a separate path for the multiple allocations. Thanks. [...] -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Support multiple pages allocation
于 2013/7/10 8:31, Joonsoo Kim 写道: On Thu, Jul 04, 2013 at 12:00:44PM +0200, Michal Hocko wrote: On Thu 04-07-13 13:24:50, Joonsoo Kim wrote: On Thu, Jul 04, 2013 at 12:01:43AM +0800, Zhang Yanfei wrote: On 07/03/2013 11:51 PM, Zhang Yanfei wrote: On 07/03/2013 11:28 PM, Michal Hocko wrote: On Wed 03-07-13 17:34:15, Joonsoo Kim wrote: [...] For one page allocation at once, this patchset makes allocator slower than before (-5%). Slowing down the most used path is a no-go. Where does this slow down come from? I guess, it might be: for one page allocation at once, comparing to the original code, this patch adds two parameters nr_pages and pages and will do extra checks for the parameter nr_pages in the allocation path. If so, adding a separate path for the multiple allocations seems better. Hello, all. I modify the code for optimizing one page allocation via likely macro. I attach a new one at the end of this mail. In this case, performance degradation for one page allocation at once is -2.5%. I guess, remained overhead comes from two added parameters. Is it unreasonable cost to support this new feature? Which benchmark you are using for this testing? I use my own module which do allocation repeatedly. I think that readahead path is one of the most used path, so this penalty looks endurable. And after supporting this feature, we can find more use cases. What about page faults? I would oppose that page faults are _much_ more frequent than read ahead so you really cannot slow them down. You mean page faults for anon? Yes. I also think that it is much more frequent than read ahead. Before futher discussion, I will try to add a separate path for the multiple allocations. Some days ago, I was thinking that this multiple allocation behaviour may be useful for vmalloc allocations. So I think it is worth trying. Thanks. [...] -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- Thanks. Zhang Yanfei -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Support multiple pages allocation
On Thu 04-07-13 13:24:50, Joonsoo Kim wrote: > On Thu, Jul 04, 2013 at 12:01:43AM +0800, Zhang Yanfei wrote: > > On 07/03/2013 11:51 PM, Zhang Yanfei wrote: > > > On 07/03/2013 11:28 PM, Michal Hocko wrote: > > >> On Wed 03-07-13 17:34:15, Joonsoo Kim wrote: > > >> [...] > > >>> For one page allocation at once, this patchset makes allocator slower > > >>> than > > >>> before (-5%). > > >> > > >> Slowing down the most used path is a no-go. Where does this slow down > > >> come from? > > > > > > I guess, it might be: for one page allocation at once, comparing to the > > > original > > > code, this patch adds two parameters nr_pages and pages and will do extra > > > checks > > > for the parameter nr_pages in the allocation path. > > > > > > > If so, adding a separate path for the multiple allocations seems better. > > Hello, all. > > I modify the code for optimizing one page allocation via likely macro. > I attach a new one at the end of this mail. > > In this case, performance degradation for one page allocation at once is > -2.5%. > I guess, remained overhead comes from two added parameters. > Is it unreasonable cost to support this new feature? Which benchmark you are using for this testing? > I think that readahead path is one of the most used path, so this penalty > looks > endurable. And after supporting this feature, we can find more use cases. What about page faults? I would oppose that page faults are _much_ more frequent than read ahead so you really cannot slow them down. [...] -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Support multiple pages allocation
On Thu 04-07-13 13:24:50, Joonsoo Kim wrote: On Thu, Jul 04, 2013 at 12:01:43AM +0800, Zhang Yanfei wrote: On 07/03/2013 11:51 PM, Zhang Yanfei wrote: On 07/03/2013 11:28 PM, Michal Hocko wrote: On Wed 03-07-13 17:34:15, Joonsoo Kim wrote: [...] For one page allocation at once, this patchset makes allocator slower than before (-5%). Slowing down the most used path is a no-go. Where does this slow down come from? I guess, it might be: for one page allocation at once, comparing to the original code, this patch adds two parameters nr_pages and pages and will do extra checks for the parameter nr_pages in the allocation path. If so, adding a separate path for the multiple allocations seems better. Hello, all. I modify the code for optimizing one page allocation via likely macro. I attach a new one at the end of this mail. In this case, performance degradation for one page allocation at once is -2.5%. I guess, remained overhead comes from two added parameters. Is it unreasonable cost to support this new feature? Which benchmark you are using for this testing? I think that readahead path is one of the most used path, so this penalty looks endurable. And after supporting this feature, we can find more use cases. What about page faults? I would oppose that page faults are _much_ more frequent than read ahead so you really cannot slow them down. [...] -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Support multiple pages allocation
On Thu, Jul 04, 2013 at 12:01:43AM +0800, Zhang Yanfei wrote:
> On 07/03/2013 11:51 PM, Zhang Yanfei wrote:
> > On 07/03/2013 11:28 PM, Michal Hocko wrote:
> >> On Wed 03-07-13 17:34:15, Joonsoo Kim wrote:
> >> [...]
> >>> For one page allocation at once, this patchset makes allocator slower than
> >>> before (-5%).
> >>
> >> Slowing down the most used path is a no-go. Where does this slow down
> >> come from?
> >
> > I guess, it might be: for one page allocation at once, comparing to the
> > original
> > code, this patch adds two parameters nr_pages and pages and will do extra
> > checks
> > for the parameter nr_pages in the allocation path.
> >
>
> If so, adding a separate path for the multiple allocations seems better.
Hello, all.
I modify the code for optimizing one page allocation via likely macro.
I attach a new one at the end of this mail.
In this case, performance degradation for one page allocation at once is -2.5%.
I guess, remained overhead comes from two added parameters.
Is it unreasonable cost to support this new feature?
I think that readahead path is one of the most used path, so this penalty looks
endurable. And after supporting this feature, we can find more use cases.
I will try to add a new function for the multiple allocations and test it. But,
IMHO, adding a new function is not good idea, because we should duplicate
various checks which are already in __alloc_pages_nodemask and even if
we introduce a new function, we cannot avoid to pass two parameters
to get_page_from_freelist(), so slight performance degradation on
one page allocation is inevitable. Anyway, I will do and test it.
Thanks.
---8<
>From cee05ad3bcf1c5774fabf797b5dc8f78f812ca36 Mon Sep 17 00:00:00 2001
From: Joonsoo Kim
Date: Wed, 26 Jun 2013 13:37:57 +0900
Subject: [PATCH] mm, page_alloc: support multiple pages allocation
This patch introduces multiple pages allocation feature to buddy
allocator. Currently, there is no ability to allocate multiple
pages at once, so we should invoke single page allocation logic
repeatedly. This has some overheads like as function call
overhead with many arguments and overhead for finding proper
node and zone.
With this patchset, we can reduce these overheads. Device I/O is
getting faster rapidly and allocator should catch up this speed.
This patch help this situation.
In this patch, I introduce new arguments, nr_pages and pages, to
core function of allocator and try to allocate multiple pages
in first attempt(fast path). I think that multiple page allocation
is not valid for slow path, so current implementation consider
just fast path.
Signed-off-by: Joonsoo Kim
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 0f615eb..8bfa87b 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -298,13 +298,15 @@ static inline void arch_alloc_page(struct page *page, int
order) { }
struct page *
__alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order,
- struct zonelist *zonelist, nodemask_t *nodemask);
+ struct zonelist *zonelist, nodemask_t *nodemask,
+ unsigned long *nr_pages, struct page **pages);
static inline struct page *
__alloc_pages(gfp_t gfp_mask, unsigned int order,
struct zonelist *zonelist)
{
- return __alloc_pages_nodemask(gfp_mask, order, zonelist, NULL);
+ return __alloc_pages_nodemask(gfp_mask, order,
+ zonelist, NULL, NULL, NULL);
}
static inline struct page *alloc_pages_node(int nid, gfp_t gfp_mask,
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 7431001..b17e48c 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -2004,7 +2004,8 @@ retry_cpuset:
}
page = __alloc_pages_nodemask(gfp, order,
policy_zonelist(gfp, pol, node),
- policy_nodemask(gfp, pol));
+ policy_nodemask(gfp, pol),
+ NULL, NULL);
if (unlikely(mpol_needs_cond_ref(pol)))
__mpol_put(pol);
if (unlikely(!put_mems_allowed(cpuset_mems_cookie) && !page))
@@ -2052,7 +2053,8 @@ retry_cpuset:
else
page = __alloc_pages_nodemask(gfp, order,
policy_zonelist(gfp, pol, numa_node_id()),
- policy_nodemask(gfp, pol));
+ policy_nodemask(gfp, pol),
+ NULL, NULL);
if (unlikely(!put_mems_allowed(cpuset_mems_cookie) && !page))
goto retry_cpuset;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c3edb62..0ba9f63 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1846,7 +1846,8 @@ static inline void init_zone_allows_reclaim(int nid)
static struct page *
get_page_from_freelist(gfp_t gfp_mask, nodemask_t *nodemask, unsigned int
order,
Re: [RFC PATCH 0/5] Support multiple pages allocation
On 07/03/2013 11:51 PM, Zhang Yanfei wrote: > On 07/03/2013 11:28 PM, Michal Hocko wrote: >> On Wed 03-07-13 17:34:15, Joonsoo Kim wrote: >> [...] >>> For one page allocation at once, this patchset makes allocator slower than >>> before (-5%). >> >> Slowing down the most used path is a no-go. Where does this slow down >> come from? > > I guess, it might be: for one page allocation at once, comparing to the > original > code, this patch adds two parameters nr_pages and pages and will do extra > checks > for the parameter nr_pages in the allocation path. > If so, adding a separate path for the multiple allocations seems better. >> >> [...] > > -- Thanks. Zhang Yanfei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Support multiple pages allocation
On 07/03/2013 11:28 PM, Michal Hocko wrote: > On Wed 03-07-13 17:34:15, Joonsoo Kim wrote: > [...] >> For one page allocation at once, this patchset makes allocator slower than >> before (-5%). > > Slowing down the most used path is a no-go. Where does this slow down > come from? I guess, it might be: for one page allocation at once, comparing to the original code, this patch adds two parameters nr_pages and pages and will do extra checks for the parameter nr_pages in the allocation path. > > [...] -- Thanks. Zhang Yanfei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Support multiple pages allocation
On Wed 03-07-13 17:34:15, Joonsoo Kim wrote: [...] > For one page allocation at once, this patchset makes allocator slower than > before (-5%). Slowing down the most used path is a no-go. Where does this slow down come from? [...] -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/5] Support multiple pages allocation
Hello. This patchset introduces multiple pages allocation feature to buddy allocator. Currently, there is no ability to allocate multiple pages at once, so we should invoke single page allocation logic repeatedly. This has some overheads like as overhead of function call with many arguments and overhead for finding proper node and zone. With this patchset, we can reduce these overheads. Here goes some experimental result of allocation test. I did the test on below setup. CPU: 4 cpus, 3.00GHz. RAM: 4 GB Kernel: v3.10 vanilla Each case of result is an average of 20 runs. Time(us) : Improvement Percentage Before Patched 1 page Patched 2 page Patched 4 page -- 128KB 5.3 0 4.4516.04% 3.2538.68% 3.75 29.25% 256KB 13.15 0 10.15 22.81% 8.8 33.08% 8.5 35.36% 512KB 72.30 34.65 52.07% 82.65 -14.32% 25 65.42% 1024KB 114.9 0 112.95 1.70% 87.55 23.80% 64.7 43.69% 2MB 131.65 0 102.35 22.26% 91.95 30.16% 126.05 4.25% 4MB 225.55 0 213.2 5.48% 181.95 19.33% 200.8 10.97% 8MB 408.6 0 442.85 -8.38% 350.4 14.24% 365.15 10.63% 16MB730.55 0 683.35 6.46% 735.5 -0.68% 698.3 4.41% 32MB1682.6 0 1665.85 1.00% 1445.1 14.12% 1157.05 31.23% 64MB3229.4 0 3463.2 -7.24% 2538.4 21.40% 1850.55 42.70% 128MB 5465.6 0 4816.2 11.88% 4448.3 18.61% 3528.25 35.45% 256MB 9526.9 0 10091.75 -5.93% 8514.5 10.63% 7978.2 16.26% 512MB 19029.05 0 20079.7 -5.52% 17059.05 10.35% 14713.65 22.68% 1024MB 37284.9 0 39453.75 -5.82% 32969.7 11.57% 28161.65 24.47% Before Patched 8 page Patched 16 page Patched 32 page --- 128KB 5.3 0 3.0542.45% 2.6550.00% 2.85 46.23% 256KB 13.15 0 8.2 37.64% 7.4543.35% 7.95 39.54% 512KB 72.30 16.876.76% 17.775.52% 14.55 79.88% 1024KB 114.9 0 60.05 47.74% 93.65 18.49% 74.2 35.42% 2MB 131.65 0 119.8 9.00% 72.644.85% 84.7 35.66% 4MB 225.55 0 227.3 -0.78% 149.95 33.52% 153.6 31.90% 8MB 408.6 0 372.5 8.84% 304.95 25.37% 340.55 16.65% 16MB730.55 0 772.2 -5.70% 567.4 22.33% 618.3 15.37% 32MB1682.6 0 1217.7 27.63% 1098.25 34.73% 1168.7 30.54% 64MB3229.4 0 2237.75 30.71% 1817.8 43.71% 1998.25 38.12% 128MB 5465.6 0 3504.25 35.89% 3466.75 36.57% 3159.35 42.20% 256MB 9526.9 0 7071.2 25.78% 7095.05 25.53% 6800.9 28.61% 512MB 19029.05 0 13640.85 28.32% 13098.2 31.17% 12778.1 32.85% 1024MB 37284.9 0 25897.15 30.54% 24875.6 33.28% 24179.3 35.15% For one page allocation at once, this patchset makes allocator slower than before (-5%). But, for more page allocation at once, this patchset makes allocator faster than before greately. At first, we can apply this feature to page cache readahead logic which allocate single page repeatedly. I attach sample implementation to this patchset(Patch 2-5). Current implementation is not yet complete. Before polishing this feature, I want to hear expert's opinion. I don't have any trouble with current allocator, however, I think that we need this feature soon, because device I/O is getting faster rapidly and allocator should catch up this speed. Thanks. Joonsoo Kim (5): mm, page_alloc: support multiple pages allocation mm, page_alloc: introduce alloc_pages_exact_node_multiple() radix-tree: introduce radix_tree_[next/prev]_present() readahead: remove end range check readhead: support multiple pages allocation for readahead include/linux/gfp.h| 16 ++-- include/linux/pagemap.h| 19 +- include/linux/radix-tree.h |4 +++ lib/radix-tree.c | 34 mm/filemap.c | 18 - mm/mempolicy.c |6 +++-- mm/page_alloc.c| 62 +++- mm/readahead.c | 46 ++-- 8 files changed, 162 insertions(+), 43 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
[RFC PATCH 0/5] Support multiple pages allocation
Hello. This patchset introduces multiple pages allocation feature to buddy allocator. Currently, there is no ability to allocate multiple pages at once, so we should invoke single page allocation logic repeatedly. This has some overheads like as overhead of function call with many arguments and overhead for finding proper node and zone. With this patchset, we can reduce these overheads. Here goes some experimental result of allocation test. I did the test on below setup. CPU: 4 cpus, 3.00GHz. RAM: 4 GB Kernel: v3.10 vanilla Each case of result is an average of 20 runs. Time(us) : Improvement Percentage Before Patched 1 page Patched 2 page Patched 4 page -- 128KB 5.3 0 4.4516.04% 3.2538.68% 3.75 29.25% 256KB 13.15 0 10.15 22.81% 8.8 33.08% 8.5 35.36% 512KB 72.30 34.65 52.07% 82.65 -14.32% 25 65.42% 1024KB 114.9 0 112.95 1.70% 87.55 23.80% 64.7 43.69% 2MB 131.65 0 102.35 22.26% 91.95 30.16% 126.05 4.25% 4MB 225.55 0 213.2 5.48% 181.95 19.33% 200.8 10.97% 8MB 408.6 0 442.85 -8.38% 350.4 14.24% 365.15 10.63% 16MB730.55 0 683.35 6.46% 735.5 -0.68% 698.3 4.41% 32MB1682.6 0 1665.85 1.00% 1445.1 14.12% 1157.05 31.23% 64MB3229.4 0 3463.2 -7.24% 2538.4 21.40% 1850.55 42.70% 128MB 5465.6 0 4816.2 11.88% 4448.3 18.61% 3528.25 35.45% 256MB 9526.9 0 10091.75 -5.93% 8514.5 10.63% 7978.2 16.26% 512MB 19029.05 0 20079.7 -5.52% 17059.05 10.35% 14713.65 22.68% 1024MB 37284.9 0 39453.75 -5.82% 32969.7 11.57% 28161.65 24.47% Before Patched 8 page Patched 16 page Patched 32 page --- 128KB 5.3 0 3.0542.45% 2.6550.00% 2.85 46.23% 256KB 13.15 0 8.2 37.64% 7.4543.35% 7.95 39.54% 512KB 72.30 16.876.76% 17.775.52% 14.55 79.88% 1024KB 114.9 0 60.05 47.74% 93.65 18.49% 74.2 35.42% 2MB 131.65 0 119.8 9.00% 72.644.85% 84.7 35.66% 4MB 225.55 0 227.3 -0.78% 149.95 33.52% 153.6 31.90% 8MB 408.6 0 372.5 8.84% 304.95 25.37% 340.55 16.65% 16MB730.55 0 772.2 -5.70% 567.4 22.33% 618.3 15.37% 32MB1682.6 0 1217.7 27.63% 1098.25 34.73% 1168.7 30.54% 64MB3229.4 0 2237.75 30.71% 1817.8 43.71% 1998.25 38.12% 128MB 5465.6 0 3504.25 35.89% 3466.75 36.57% 3159.35 42.20% 256MB 9526.9 0 7071.2 25.78% 7095.05 25.53% 6800.9 28.61% 512MB 19029.05 0 13640.85 28.32% 13098.2 31.17% 12778.1 32.85% 1024MB 37284.9 0 25897.15 30.54% 24875.6 33.28% 24179.3 35.15% For one page allocation at once, this patchset makes allocator slower than before (-5%). But, for more page allocation at once, this patchset makes allocator faster than before greately. At first, we can apply this feature to page cache readahead logic which allocate single page repeatedly. I attach sample implementation to this patchset(Patch 2-5). Current implementation is not yet complete. Before polishing this feature, I want to hear expert's opinion. I don't have any trouble with current allocator, however, I think that we need this feature soon, because device I/O is getting faster rapidly and allocator should catch up this speed. Thanks. Joonsoo Kim (5): mm, page_alloc: support multiple pages allocation mm, page_alloc: introduce alloc_pages_exact_node_multiple() radix-tree: introduce radix_tree_[next/prev]_present() readahead: remove end range check readhead: support multiple pages allocation for readahead include/linux/gfp.h| 16 ++-- include/linux/pagemap.h| 19 +- include/linux/radix-tree.h |4 +++ lib/radix-tree.c | 34 mm/filemap.c | 18 - mm/mempolicy.c |6 +++-- mm/page_alloc.c| 62 +++- mm/readahead.c | 46 ++-- 8 files changed, 162 insertions(+), 43 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to
Re: [RFC PATCH 0/5] Support multiple pages allocation
On Wed 03-07-13 17:34:15, Joonsoo Kim wrote: [...] For one page allocation at once, this patchset makes allocator slower than before (-5%). Slowing down the most used path is a no-go. Where does this slow down come from? [...] -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Support multiple pages allocation
On 07/03/2013 11:28 PM, Michal Hocko wrote: On Wed 03-07-13 17:34:15, Joonsoo Kim wrote: [...] For one page allocation at once, this patchset makes allocator slower than before (-5%). Slowing down the most used path is a no-go. Where does this slow down come from? I guess, it might be: for one page allocation at once, comparing to the original code, this patch adds two parameters nr_pages and pages and will do extra checks for the parameter nr_pages in the allocation path. [...] -- Thanks. Zhang Yanfei -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Support multiple pages allocation
On 07/03/2013 11:51 PM, Zhang Yanfei wrote: On 07/03/2013 11:28 PM, Michal Hocko wrote: On Wed 03-07-13 17:34:15, Joonsoo Kim wrote: [...] For one page allocation at once, this patchset makes allocator slower than before (-5%). Slowing down the most used path is a no-go. Where does this slow down come from? I guess, it might be: for one page allocation at once, comparing to the original code, this patch adds two parameters nr_pages and pages and will do extra checks for the parameter nr_pages in the allocation path. If so, adding a separate path for the multiple allocations seems better. [...] -- Thanks. Zhang Yanfei -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Support multiple pages allocation
On Thu, Jul 04, 2013 at 12:01:43AM +0800, Zhang Yanfei wrote:
On 07/03/2013 11:51 PM, Zhang Yanfei wrote:
On 07/03/2013 11:28 PM, Michal Hocko wrote:
On Wed 03-07-13 17:34:15, Joonsoo Kim wrote:
[...]
For one page allocation at once, this patchset makes allocator slower than
before (-5%).
Slowing down the most used path is a no-go. Where does this slow down
come from?
I guess, it might be: for one page allocation at once, comparing to the
original
code, this patch adds two parameters nr_pages and pages and will do extra
checks
for the parameter nr_pages in the allocation path.
If so, adding a separate path for the multiple allocations seems better.
Hello, all.
I modify the code for optimizing one page allocation via likely macro.
I attach a new one at the end of this mail.
In this case, performance degradation for one page allocation at once is -2.5%.
I guess, remained overhead comes from two added parameters.
Is it unreasonable cost to support this new feature?
I think that readahead path is one of the most used path, so this penalty looks
endurable. And after supporting this feature, we can find more use cases.
I will try to add a new function for the multiple allocations and test it. But,
IMHO, adding a new function is not good idea, because we should duplicate
various checks which are already in __alloc_pages_nodemask and even if
we introduce a new function, we cannot avoid to pass two parameters
to get_page_from_freelist(), so slight performance degradation on
one page allocation is inevitable. Anyway, I will do and test it.
Thanks.
---8
From cee05ad3bcf1c5774fabf797b5dc8f78f812ca36 Mon Sep 17 00:00:00 2001
From: Joonsoo Kim iamjoonsoo@lge.com
Date: Wed, 26 Jun 2013 13:37:57 +0900
Subject: [PATCH] mm, page_alloc: support multiple pages allocation
This patch introduces multiple pages allocation feature to buddy
allocator. Currently, there is no ability to allocate multiple
pages at once, so we should invoke single page allocation logic
repeatedly. This has some overheads like as function call
overhead with many arguments and overhead for finding proper
node and zone.
With this patchset, we can reduce these overheads. Device I/O is
getting faster rapidly and allocator should catch up this speed.
This patch help this situation.
In this patch, I introduce new arguments, nr_pages and pages, to
core function of allocator and try to allocate multiple pages
in first attempt(fast path). I think that multiple page allocation
is not valid for slow path, so current implementation consider
just fast path.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 0f615eb..8bfa87b 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -298,13 +298,15 @@ static inline void arch_alloc_page(struct page *page, int
order) { }
struct page *
__alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order,
- struct zonelist *zonelist, nodemask_t *nodemask);
+ struct zonelist *zonelist, nodemask_t *nodemask,
+ unsigned long *nr_pages, struct page **pages);
static inline struct page *
__alloc_pages(gfp_t gfp_mask, unsigned int order,
struct zonelist *zonelist)
{
- return __alloc_pages_nodemask(gfp_mask, order, zonelist, NULL);
+ return __alloc_pages_nodemask(gfp_mask, order,
+ zonelist, NULL, NULL, NULL);
}
static inline struct page *alloc_pages_node(int nid, gfp_t gfp_mask,
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 7431001..b17e48c 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -2004,7 +2004,8 @@ retry_cpuset:
}
page = __alloc_pages_nodemask(gfp, order,
policy_zonelist(gfp, pol, node),
- policy_nodemask(gfp, pol));
+ policy_nodemask(gfp, pol),
+ NULL, NULL);
if (unlikely(mpol_needs_cond_ref(pol)))
__mpol_put(pol);
if (unlikely(!put_mems_allowed(cpuset_mems_cookie) !page))
@@ -2052,7 +2053,8 @@ retry_cpuset:
else
page = __alloc_pages_nodemask(gfp, order,
policy_zonelist(gfp, pol, numa_node_id()),
- policy_nodemask(gfp, pol));
+ policy_nodemask(gfp, pol),
+ NULL, NULL);
if (unlikely(!put_mems_allowed(cpuset_mems_cookie) !page))
goto retry_cpuset;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c3edb62..0ba9f63 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1846,7 +1846,8 @@ static inline void init_zone_allows_reclaim(int nid)
static struct page *
get_page_from_freelist(gfp_t gfp_mask, nodemask_t *nodemask, unsigned int
order,
