On Fri, Apr 25 2014, Joonsoo Kim wrote:
> Subject: [PATCH] mm-compaction-cleanup-isolate_freepages-fix3
>
> What I did here is taking end_pfn out of the loop and considering zone
> boundary once. After then, we can just set previous pfn to end_pfn on
> every iteration to move scanning window. With
On Fri, Apr 25 2014, Joonsoo Kim wrote:
Subject: [PATCH] mm-compaction-cleanup-isolate_freepages-fix3
What I did here is taking end_pfn out of the loop and considering zone
boundary once. After then, we can just set previous pfn to end_pfn on
every iteration to move scanning window. With this
On 04/25/2014 10:29 AM, Joonsoo Kim wrote:
On Wed, Apr 23, 2014 at 04:31:14PM +0200, Vlastimil Babka wrote:
Hello,
How about doing more clean-up at this time?
What I did is that taking end_pfn out of the loop and consider zone
boundary once. After then, we just subtract pageblock_nr_pages on
On 04/25/2014 10:29 AM, Joonsoo Kim wrote:
On Wed, Apr 23, 2014 at 04:31:14PM +0200, Vlastimil Babka wrote:
Hello,
How about doing more clean-up at this time?
What I did is that taking end_pfn out of the loop and consider zone
boundary once. After then, we just subtract pageblock_nr_pages on
On Wed, Apr 23, 2014 at 04:31:14PM +0200, Vlastimil Babka wrote:
> >>>
> >>> Hello,
> >>>
> >>> How about doing more clean-up at this time?
> >>>
> >>> What I did is that taking end_pfn out of the loop and consider zone
> >>> boundary once. After then, we just subtract pageblock_nr_pages on
> >>>
On Wed, Apr 23, 2014 at 04:31:14PM +0200, Vlastimil Babka wrote:
Hello,
How about doing more clean-up at this time?
What I did is that taking end_pfn out of the loop and consider zone
boundary once. After then, we just subtract pageblock_nr_pages on
every iteration. With this
>>>
>>> Hello,
>>>
>>> How about doing more clean-up at this time?
>>>
>>> What I did is that taking end_pfn out of the loop and consider zone
>>> boundary once. After then, we just subtract pageblock_nr_pages on
>>> every iteration. With this change, we can remove local variable, z_end_pfn.
>>>
2014-04-23 16:30 GMT+09:00 Vlastimil Babka :
> On 04/23/2014 04:58 AM, Joonsoo Kim wrote:
>> On Tue, Apr 22, 2014 at 03:17:30PM +0200, Vlastimil Babka wrote:
>>> On 04/22/2014 08:52 AM, Minchan Kim wrote:
On Tue, Apr 22, 2014 at 08:33:35AM +0200, Vlastimil Babka wrote:
> On 22.4.2014
On 04/23/2014 04:58 AM, Joonsoo Kim wrote:
> On Tue, Apr 22, 2014 at 03:17:30PM +0200, Vlastimil Babka wrote:
>> On 04/22/2014 08:52 AM, Minchan Kim wrote:
>>> On Tue, Apr 22, 2014 at 08:33:35AM +0200, Vlastimil Babka wrote:
On 22.4.2014 1:53, Minchan Kim wrote:
> On Mon, Apr 21, 2014 at
On 04/23/2014 04:58 AM, Joonsoo Kim wrote:
On Tue, Apr 22, 2014 at 03:17:30PM +0200, Vlastimil Babka wrote:
On 04/22/2014 08:52 AM, Minchan Kim wrote:
On Tue, Apr 22, 2014 at 08:33:35AM +0200, Vlastimil Babka wrote:
On 22.4.2014 1:53, Minchan Kim wrote:
On Mon, Apr 21, 2014 at 11:43:24PM
2014-04-23 16:30 GMT+09:00 Vlastimil Babka vba...@suse.cz:
On 04/23/2014 04:58 AM, Joonsoo Kim wrote:
On Tue, Apr 22, 2014 at 03:17:30PM +0200, Vlastimil Babka wrote:
On 04/22/2014 08:52 AM, Minchan Kim wrote:
On Tue, Apr 22, 2014 at 08:33:35AM +0200, Vlastimil Babka wrote:
On 22.4.2014 1:53,
Hello,
How about doing more clean-up at this time?
What I did is that taking end_pfn out of the loop and consider zone
boundary once. After then, we just subtract pageblock_nr_pages on
every iteration. With this change, we can remove local variable, z_end_pfn.
Another things I did are
On Tue, Apr 22, 2014 at 03:17:30PM +0200, Vlastimil Babka wrote:
> On 04/22/2014 08:52 AM, Minchan Kim wrote:
> > On Tue, Apr 22, 2014 at 08:33:35AM +0200, Vlastimil Babka wrote:
> >> On 22.4.2014 1:53, Minchan Kim wrote:
> >>> On Mon, Apr 21, 2014 at 11:43:24PM +0200, Vlastimil Babka wrote:
>
On 04/22/2014 08:52 AM, Minchan Kim wrote:
> On Tue, Apr 22, 2014 at 08:33:35AM +0200, Vlastimil Babka wrote:
>> On 22.4.2014 1:53, Minchan Kim wrote:
>>> On Mon, Apr 21, 2014 at 11:43:24PM +0200, Vlastimil Babka wrote:
On 21.4.2014 21:41, Andrew Morton wrote:
> On Thu, 17 Apr 2014
On Tue, Apr 22, 2014 at 08:33:35AM +0200, Vlastimil Babka wrote:
> On 22.4.2014 1:53, Minchan Kim wrote:
> >On Mon, Apr 21, 2014 at 11:43:24PM +0200, Vlastimil Babka wrote:
> >>On 21.4.2014 21:41, Andrew Morton wrote:
> >>>On Thu, 17 Apr 2014 09:07:45 +0900 Minchan Kim wrote:
> >>>
> Hi
On 22.4.2014 1:53, Minchan Kim wrote:
On Mon, Apr 21, 2014 at 11:43:24PM +0200, Vlastimil Babka wrote:
On 21.4.2014 21:41, Andrew Morton wrote:
On Thu, 17 Apr 2014 09:07:45 +0900 Minchan Kim wrote:
Hi Vlastimil,
Below just nitpicks.
It seems you were ignored ;)
Oops, I managed to miss
On 22.4.2014 1:53, Minchan Kim wrote:
On Mon, Apr 21, 2014 at 11:43:24PM +0200, Vlastimil Babka wrote:
On 21.4.2014 21:41, Andrew Morton wrote:
On Thu, 17 Apr 2014 09:07:45 +0900 Minchan Kim minc...@kernel.org wrote:
Hi Vlastimil,
Below just nitpicks.
It seems you were ignored ;)
Oops, I
On Tue, Apr 22, 2014 at 08:33:35AM +0200, Vlastimil Babka wrote:
On 22.4.2014 1:53, Minchan Kim wrote:
On Mon, Apr 21, 2014 at 11:43:24PM +0200, Vlastimil Babka wrote:
On 21.4.2014 21:41, Andrew Morton wrote:
On Thu, 17 Apr 2014 09:07:45 +0900 Minchan Kim minc...@kernel.org wrote:
Hi
On 04/22/2014 08:52 AM, Minchan Kim wrote:
On Tue, Apr 22, 2014 at 08:33:35AM +0200, Vlastimil Babka wrote:
On 22.4.2014 1:53, Minchan Kim wrote:
On Mon, Apr 21, 2014 at 11:43:24PM +0200, Vlastimil Babka wrote:
On 21.4.2014 21:41, Andrew Morton wrote:
On Thu, 17 Apr 2014 09:07:45 +0900
On Tue, Apr 22, 2014 at 03:17:30PM +0200, Vlastimil Babka wrote:
On 04/22/2014 08:52 AM, Minchan Kim wrote:
On Tue, Apr 22, 2014 at 08:33:35AM +0200, Vlastimil Babka wrote:
On 22.4.2014 1:53, Minchan Kim wrote:
On Mon, Apr 21, 2014 at 11:43:24PM +0200, Vlastimil Babka wrote:
On 21.4.2014
On Mon, Apr 21, 2014 at 11:43:24PM +0200, Vlastimil Babka wrote:
> On 21.4.2014 21:41, Andrew Morton wrote:
> >On Thu, 17 Apr 2014 09:07:45 +0900 Minchan Kim wrote:
> >
> >>Hi Vlastimil,
> >>
> >>Below just nitpicks.
> >It seems you were ignored ;)
>
> Oops, I managed to miss your e-mail, sorry.
On 21.4.2014 21:41, Andrew Morton wrote:
On Thu, 17 Apr 2014 09:07:45 +0900 Minchan Kim wrote:
Hi Vlastimil,
Below just nitpicks.
It seems you were ignored ;)
Oops, I managed to miss your e-mail, sorry.
{
struct page *page;
- unsigned long high_pfn, low_pfn, pfn,
On Thu, 17 Apr 2014 09:07:45 +0900 Minchan Kim wrote:
> Hi Vlastimil,
>
> Below just nitpicks.
It seems you were ignored ;)
> > {
> > struct page *page;
> > - unsigned long high_pfn, low_pfn, pfn, z_end_pfn;
> > + unsigned long pfn, low_pfn, next_free_pfn, z_end_pfn;
>
> Could you
On Thu, 17 Apr 2014 09:07:45 +0900 Minchan Kim minc...@kernel.org wrote:
Hi Vlastimil,
Below just nitpicks.
It seems you were ignored ;)
{
struct page *page;
- unsigned long high_pfn, low_pfn, pfn, z_end_pfn;
+ unsigned long pfn, low_pfn, next_free_pfn, z_end_pfn;
Could
On 21.4.2014 21:41, Andrew Morton wrote:
On Thu, 17 Apr 2014 09:07:45 +0900 Minchan Kim minc...@kernel.org wrote:
Hi Vlastimil,
Below just nitpicks.
It seems you were ignored ;)
Oops, I managed to miss your e-mail, sorry.
{
struct page *page;
- unsigned long high_pfn,
On Mon, Apr 21, 2014 at 11:43:24PM +0200, Vlastimil Babka wrote:
On 21.4.2014 21:41, Andrew Morton wrote:
On Thu, 17 Apr 2014 09:07:45 +0900 Minchan Kim minc...@kernel.org wrote:
Hi Vlastimil,
Below just nitpicks.
It seems you were ignored ;)
Oops, I managed to miss your e-mail, sorry.
Hi Vlastimil,
Below just nitpicks.
On Tue, Apr 15, 2014 at 11:18:27AM +0200, Vlastimil Babka wrote:
> isolate_freepages() is currently somewhat hard to follow thanks to many
> different pfn variables. Especially misleading is the name 'high_pfn' which
> looks like it is related to the 'low_pfn'
On 04/15/2014 05:18 AM, Vlastimil Babka wrote:
isolate_freepages() is currently somewhat hard to follow thanks to many
different pfn variables. Especially misleading is the name 'high_pfn' which
looks like it is related to the 'low_pfn' variable, but in fact it is not.
This patch renames the
On 04/15/2014 05:18 AM, Vlastimil Babka wrote:
isolate_freepages() is currently somewhat hard to follow thanks to many
different pfn variables. Especially misleading is the name 'high_pfn' which
looks like it is related to the 'low_pfn' variable, but in fact it is not.
This patch renames the
Hi Vlastimil,
Below just nitpicks.
On Tue, Apr 15, 2014 at 11:18:27AM +0200, Vlastimil Babka wrote:
isolate_freepages() is currently somewhat hard to follow thanks to many
different pfn variables. Especially misleading is the name 'high_pfn' which
looks like it is related to the 'low_pfn'
On Tue, Apr 15, 2014 at 11:18:27AM +0200, Vlastimil Babka wrote:
> isolate_freepages() is currently somewhat hard to follow thanks to many
> different pfn variables. Especially misleading is the name 'high_pfn' which
> looks like it is related to the 'low_pfn' variable, but in fact it is not.
>
>
isolate_freepages() is currently somewhat hard to follow thanks to many
different pfn variables. Especially misleading is the name 'high_pfn' which
looks like it is related to the 'low_pfn' variable, but in fact it is not.
This patch renames the 'high_pfn' variable to a hopefully less confusing
isolate_freepages() is currently somewhat hard to follow thanks to many
different pfn variables. Especially misleading is the name 'high_pfn' which
looks like it is related to the 'low_pfn' variable, but in fact it is not.
This patch renames the 'high_pfn' variable to a hopefully less confusing
On Tue, Apr 15, 2014 at 11:18:27AM +0200, Vlastimil Babka wrote:
isolate_freepages() is currently somewhat hard to follow thanks to many
different pfn variables. Especially misleading is the name 'high_pfn' which
looks like it is related to the 'low_pfn' variable, but in fact it is not.
This
34 matches
Mail list logo
