Re: [PATCH 1/3] mm/compaction: enhance trace output to know more about compaction internals
On Fri, Jan 09, 2015 at 10:57:10AM +, Mel Gorman wrote: > On Thu, Jan 08, 2015 at 09:46:27AM +0100, Vlastimil Babka wrote: > > On 01/08/2015 09:18 AM, Joonsoo Kim wrote: > > > On Tue, Jan 06, 2015 at 10:05:39AM +0100, Vlastimil Babka wrote: > > >> On 12/03/2014 08:52 AM, Joonsoo Kim wrote: > > >> > It'd be useful to know where the both scanner is start. And, it also be > > >> > useful to know current range where compaction work. It will help to > > >> > find > > >> > odd behaviour or problem on compaction. > > >> > > >> Overall it looks good, just two questions: > > >> 1) Why change the pfn output to hexadecimal with different printf layout > > >> and > > >> change the variable names and? Is it that better to warrant people > > >> having to > > >> potentially modify their scripts parsing the old output? > > > > > > Deciaml output has really bad readability since we manage all pages by > > > order > > > of 2 which is well represented by hexadecimal. With hex output, we can > > > easily notice whether we move out from one pageblock to another one. > > > > OK. I don't have any strong objection, maybe Mel should comment on this as > > the > > author of most of the tracepoints? But if it happens, I think converting > > the old > > tracepoints to new hexadecimal format should be a separate patch from > > adding the > > new ones. > > > > To date, I'm not aware of any user-space programs that heavily depend on > the formatting. The scripts I am aware of are ad-hoc and easily modified > to adapt to format changes. LTT-NG is the only tool that might be > depending on trace point formats but I severely doubt it's interested in > this particular tracepoint. Okay. Thanks for confirmation! Thanks. -- 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: [PATCH 1/3] mm/compaction: enhance trace output to know more about compaction internals
On Fri, Jan 09, 2015 at 10:57:10AM +, Mel Gorman wrote: On Thu, Jan 08, 2015 at 09:46:27AM +0100, Vlastimil Babka wrote: On 01/08/2015 09:18 AM, Joonsoo Kim wrote: On Tue, Jan 06, 2015 at 10:05:39AM +0100, Vlastimil Babka wrote: On 12/03/2014 08:52 AM, Joonsoo Kim wrote: It'd be useful to know where the both scanner is start. And, it also be useful to know current range where compaction work. It will help to find odd behaviour or problem on compaction. Overall it looks good, just two questions: 1) Why change the pfn output to hexadecimal with different printf layout and change the variable names and? Is it that better to warrant people having to potentially modify their scripts parsing the old output? Deciaml output has really bad readability since we manage all pages by order of 2 which is well represented by hexadecimal. With hex output, we can easily notice whether we move out from one pageblock to another one. OK. I don't have any strong objection, maybe Mel should comment on this as the author of most of the tracepoints? But if it happens, I think converting the old tracepoints to new hexadecimal format should be a separate patch from adding the new ones. To date, I'm not aware of any user-space programs that heavily depend on the formatting. The scripts I am aware of are ad-hoc and easily modified to adapt to format changes. LTT-NG is the only tool that might be depending on trace point formats but I severely doubt it's interested in this particular tracepoint. Okay. Thanks for confirmation! Thanks. -- 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: [PATCH 1/3] mm/compaction: enhance trace output to know more about compaction internals
On Thu, Jan 08, 2015 at 09:46:27AM +0100, Vlastimil Babka wrote: > On 01/08/2015 09:18 AM, Joonsoo Kim wrote: > > On Tue, Jan 06, 2015 at 10:05:39AM +0100, Vlastimil Babka wrote: > >> On 12/03/2014 08:52 AM, Joonsoo Kim wrote: > >> > It'd be useful to know where the both scanner is start. And, it also be > >> > useful to know current range where compaction work. It will help to find > >> > odd behaviour or problem on compaction. > >> > >> Overall it looks good, just two questions: > >> 1) Why change the pfn output to hexadecimal with different printf layout > >> and > >> change the variable names and? Is it that better to warrant people having > >> to > >> potentially modify their scripts parsing the old output? > > > > Deciaml output has really bad readability since we manage all pages by order > > of 2 which is well represented by hexadecimal. With hex output, we can > > easily notice whether we move out from one pageblock to another one. > > OK. I don't have any strong objection, maybe Mel should comment on this as the > author of most of the tracepoints? But if it happens, I think converting the > old > tracepoints to new hexadecimal format should be a separate patch from adding > the > new ones. > To date, I'm not aware of any user-space programs that heavily depend on the formatting. The scripts I am aware of are ad-hoc and easily modified to adapt to format changes. LTT-NG is the only tool that might be depending on trace point formats but I severely doubt it's interested in this particular tracepoint. -- Mel Gorman 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: [PATCH 1/3] mm/compaction: enhance trace output to know more about compaction internals
On Thu, Jan 08, 2015 at 09:46:27AM +0100, Vlastimil Babka wrote: On 01/08/2015 09:18 AM, Joonsoo Kim wrote: On Tue, Jan 06, 2015 at 10:05:39AM +0100, Vlastimil Babka wrote: On 12/03/2014 08:52 AM, Joonsoo Kim wrote: It'd be useful to know where the both scanner is start. And, it also be useful to know current range where compaction work. It will help to find odd behaviour or problem on compaction. Overall it looks good, just two questions: 1) Why change the pfn output to hexadecimal with different printf layout and change the variable names and? Is it that better to warrant people having to potentially modify their scripts parsing the old output? Deciaml output has really bad readability since we manage all pages by order of 2 which is well represented by hexadecimal. With hex output, we can easily notice whether we move out from one pageblock to another one. OK. I don't have any strong objection, maybe Mel should comment on this as the author of most of the tracepoints? But if it happens, I think converting the old tracepoints to new hexadecimal format should be a separate patch from adding the new ones. To date, I'm not aware of any user-space programs that heavily depend on the formatting. The scripts I am aware of are ad-hoc and easily modified to adapt to format changes. LTT-NG is the only tool that might be depending on trace point formats but I severely doubt it's interested in this particular tracepoint. -- Mel Gorman 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: [PATCH 1/3] mm/compaction: enhance trace output to know more about compaction internals
On Thu, Jan 08, 2015 at 09:46:27AM +0100, Vlastimil Babka wrote: > On 01/08/2015 09:18 AM, Joonsoo Kim wrote: > > On Tue, Jan 06, 2015 at 10:05:39AM +0100, Vlastimil Babka wrote: > >> On 12/03/2014 08:52 AM, Joonsoo Kim wrote: > >> > It'd be useful to know where the both scanner is start. And, it also be > >> > useful to know current range where compaction work. It will help to find > >> > odd behaviour or problem on compaction. > >> > >> Overall it looks good, just two questions: > >> 1) Why change the pfn output to hexadecimal with different printf layout > >> and > >> change the variable names and? Is it that better to warrant people having > >> to > >> potentially modify their scripts parsing the old output? > > > > Deciaml output has really bad readability since we manage all pages by order > > of 2 which is well represented by hexadecimal. With hex output, we can > > easily notice whether we move out from one pageblock to another one. > > OK. I don't have any strong objection, maybe Mel should comment on this as the > author of most of the tracepoints? But if it happens, I think converting the > old > tracepoints to new hexadecimal format should be a separate patch from adding > the > new ones. Okay. > > >> 2) Would it be useful to also print in the mm_compaction_isolate_template > >> based > >> tracepoints, pfn of where the particular scanner left off a block > >> prematurely? > >> It doesn't always match start_pfn + nr_scanned. > > > > With start_pfn and end_pfn, detailed analysis is possible. We can know > > pageblock > > where we actually scan and isolate and how much pages we try in that > > pageblock and can guess why it doesn't become freepage with pageblock > > order roughly. > > > > nr_scanned is just different metric. end_pfn don't need to match with > > start_pfn + nr_scanned. > > Well that's part of my point. end_pfn is the end of the pageblock. nr_scanned > might be lower than end_pfn - start_pfn, because we terminate in the middle of > the pageblock. But it might be also lower, because we e.g. skip higher-order > free pages. So we don't recognize where we terminated early. Ah... now I see your point and found my mistake. My intention is also to print terminated pfn rather than end_pfn of pageblock. :/ I will change it to print pfn where we terminate scanning. Thanks. -- 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: [PATCH 1/3] mm/compaction: enhance trace output to know more about compaction internals
On 01/08/2015 09:18 AM, Joonsoo Kim wrote: > On Tue, Jan 06, 2015 at 10:05:39AM +0100, Vlastimil Babka wrote: >> On 12/03/2014 08:52 AM, Joonsoo Kim wrote: >> > It'd be useful to know where the both scanner is start. And, it also be >> > useful to know current range where compaction work. It will help to find >> > odd behaviour or problem on compaction. >> >> Overall it looks good, just two questions: >> 1) Why change the pfn output to hexadecimal with different printf layout and >> change the variable names and? Is it that better to warrant people having to >> potentially modify their scripts parsing the old output? > > Deciaml output has really bad readability since we manage all pages by order > of 2 which is well represented by hexadecimal. With hex output, we can > easily notice whether we move out from one pageblock to another one. OK. I don't have any strong objection, maybe Mel should comment on this as the author of most of the tracepoints? But if it happens, I think converting the old tracepoints to new hexadecimal format should be a separate patch from adding the new ones. >> 2) Would it be useful to also print in the mm_compaction_isolate_template >> based >> tracepoints, pfn of where the particular scanner left off a block >> prematurely? >> It doesn't always match start_pfn + nr_scanned. > > With start_pfn and end_pfn, detailed analysis is possible. We can know > pageblock > where we actually scan and isolate and how much pages we try in that > pageblock and can guess why it doesn't become freepage with pageblock > order roughly. > > nr_scanned is just different metric. end_pfn don't need to match with > start_pfn + nr_scanned. Well that's part of my point. end_pfn is the end of the pageblock. nr_scanned might be lower than end_pfn - start_pfn, because we terminate in the middle of the pageblock. But it might be also lower, because we e.g. skip higher-order free pages. So we don't recognize where we terminated early. > Thanks. > > -- > 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: [PATCH 1/3] mm/compaction: enhance trace output to know more about compaction internals
On Tue, Jan 06, 2015 at 10:05:39AM +0100, Vlastimil Babka wrote: > On 12/03/2014 08:52 AM, Joonsoo Kim wrote: > > It'd be useful to know where the both scanner is start. And, it also be > > useful to know current range where compaction work. It will help to find > > odd behaviour or problem on compaction. > > Overall it looks good, just two questions: > 1) Why change the pfn output to hexadecimal with different printf layout and > change the variable names and? Is it that better to warrant people having to > potentially modify their scripts parsing the old output? Deciaml output has really bad readability since we manage all pages by order of 2 which is well represented by hexadecimal. With hex output, we can easily notice whether we move out from one pageblock to another one. > 2) Would it be useful to also print in the mm_compaction_isolate_template > based > tracepoints, pfn of where the particular scanner left off a block prematurely? > It doesn't always match start_pfn + nr_scanned. With start_pfn and end_pfn, detailed analysis is possible. We can know pageblock where we actually scan and isolate and how much pages we try in that pageblock and can guess why it doesn't become freepage with pageblock order roughly. nr_scanned is just different metric. end_pfn don't need to match with start_pfn + nr_scanned. Thanks. -- 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: [PATCH 1/3] mm/compaction: enhance trace output to know more about compaction internals
On Thu, Jan 08, 2015 at 09:46:27AM +0100, Vlastimil Babka wrote: On 01/08/2015 09:18 AM, Joonsoo Kim wrote: On Tue, Jan 06, 2015 at 10:05:39AM +0100, Vlastimil Babka wrote: On 12/03/2014 08:52 AM, Joonsoo Kim wrote: It'd be useful to know where the both scanner is start. And, it also be useful to know current range where compaction work. It will help to find odd behaviour or problem on compaction. Overall it looks good, just two questions: 1) Why change the pfn output to hexadecimal with different printf layout and change the variable names and? Is it that better to warrant people having to potentially modify their scripts parsing the old output? Deciaml output has really bad readability since we manage all pages by order of 2 which is well represented by hexadecimal. With hex output, we can easily notice whether we move out from one pageblock to another one. OK. I don't have any strong objection, maybe Mel should comment on this as the author of most of the tracepoints? But if it happens, I think converting the old tracepoints to new hexadecimal format should be a separate patch from adding the new ones. Okay. 2) Would it be useful to also print in the mm_compaction_isolate_template based tracepoints, pfn of where the particular scanner left off a block prematurely? It doesn't always match start_pfn + nr_scanned. With start_pfn and end_pfn, detailed analysis is possible. We can know pageblock where we actually scan and isolate and how much pages we try in that pageblock and can guess why it doesn't become freepage with pageblock order roughly. nr_scanned is just different metric. end_pfn don't need to match with start_pfn + nr_scanned. Well that's part of my point. end_pfn is the end of the pageblock. nr_scanned might be lower than end_pfn - start_pfn, because we terminate in the middle of the pageblock. But it might be also lower, because we e.g. skip higher-order free pages. So we don't recognize where we terminated early. Ah... now I see your point and found my mistake. My intention is also to print terminated pfn rather than end_pfn of pageblock. :/ I will change it to print pfn where we terminate scanning. Thanks. -- 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: [PATCH 1/3] mm/compaction: enhance trace output to know more about compaction internals
On Tue, Jan 06, 2015 at 10:05:39AM +0100, Vlastimil Babka wrote: On 12/03/2014 08:52 AM, Joonsoo Kim wrote: It'd be useful to know where the both scanner is start. And, it also be useful to know current range where compaction work. It will help to find odd behaviour or problem on compaction. Overall it looks good, just two questions: 1) Why change the pfn output to hexadecimal with different printf layout and change the variable names and? Is it that better to warrant people having to potentially modify their scripts parsing the old output? Deciaml output has really bad readability since we manage all pages by order of 2 which is well represented by hexadecimal. With hex output, we can easily notice whether we move out from one pageblock to another one. 2) Would it be useful to also print in the mm_compaction_isolate_template based tracepoints, pfn of where the particular scanner left off a block prematurely? It doesn't always match start_pfn + nr_scanned. With start_pfn and end_pfn, detailed analysis is possible. We can know pageblock where we actually scan and isolate and how much pages we try in that pageblock and can guess why it doesn't become freepage with pageblock order roughly. nr_scanned is just different metric. end_pfn don't need to match with start_pfn + nr_scanned. Thanks. -- 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: [PATCH 1/3] mm/compaction: enhance trace output to know more about compaction internals
On 01/08/2015 09:18 AM, Joonsoo Kim wrote: On Tue, Jan 06, 2015 at 10:05:39AM +0100, Vlastimil Babka wrote: On 12/03/2014 08:52 AM, Joonsoo Kim wrote: It'd be useful to know where the both scanner is start. And, it also be useful to know current range where compaction work. It will help to find odd behaviour or problem on compaction. Overall it looks good, just two questions: 1) Why change the pfn output to hexadecimal with different printf layout and change the variable names and? Is it that better to warrant people having to potentially modify their scripts parsing the old output? Deciaml output has really bad readability since we manage all pages by order of 2 which is well represented by hexadecimal. With hex output, we can easily notice whether we move out from one pageblock to another one. OK. I don't have any strong objection, maybe Mel should comment on this as the author of most of the tracepoints? But if it happens, I think converting the old tracepoints to new hexadecimal format should be a separate patch from adding the new ones. 2) Would it be useful to also print in the mm_compaction_isolate_template based tracepoints, pfn of where the particular scanner left off a block prematurely? It doesn't always match start_pfn + nr_scanned. With start_pfn and end_pfn, detailed analysis is possible. We can know pageblock where we actually scan and isolate and how much pages we try in that pageblock and can guess why it doesn't become freepage with pageblock order roughly. nr_scanned is just different metric. end_pfn don't need to match with start_pfn + nr_scanned. Well that's part of my point. end_pfn is the end of the pageblock. nr_scanned might be lower than end_pfn - start_pfn, because we terminate in the middle of the pageblock. But it might be also lower, because we e.g. skip higher-order free pages. So we don't recognize where we terminated early. Thanks. -- 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: [PATCH 1/3] mm/compaction: enhance trace output to know more about compaction internals
On 12/03/2014 08:52 AM, Joonsoo Kim wrote: > It'd be useful to know where the both scanner is start. And, it also be > useful to know current range where compaction work. It will help to find > odd behaviour or problem on compaction. Overall it looks good, just two questions: 1) Why change the pfn output to hexadecimal with different printf layout and change the variable names and? Is it that better to warrant people having to potentially modify their scripts parsing the old output? 2) Would it be useful to also print in the mm_compaction_isolate_template based tracepoints, pfn of where the particular scanner left off a block prematurely? It doesn't always match start_pfn + nr_scanned. Thanks, Vlastimil -- 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: [PATCH 1/3] mm/compaction: enhance trace output to know more about compaction internals
On 12/03/2014 08:52 AM, Joonsoo Kim wrote: It'd be useful to know where the both scanner is start. And, it also be useful to know current range where compaction work. It will help to find odd behaviour or problem on compaction. Overall it looks good, just two questions: 1) Why change the pfn output to hexadecimal with different printf layout and change the variable names and? Is it that better to warrant people having to potentially modify their scripts parsing the old output? 2) Would it be useful to also print in the mm_compaction_isolate_template based tracepoints, pfn of where the particular scanner left off a block prematurely? It doesn't always match start_pfn + nr_scanned. Thanks, Vlastimil -- 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: [PATCH 1/3] mm/compaction: enhance trace output to know more about compaction internals
On 01/05/2015 03:33 AM, Joonsoo Kim wrote: > On Wed, Dec 03, 2014 at 04:52:05PM +0900, Joonsoo Kim wrote: >> It'd be useful to know where the both scanner is start. And, it also be >> useful to know current range where compaction work. It will help to find >> odd behaviour or problem on compaction. >> >> Signed-off-by: Joonsoo Kim > > Hello, Andrew and Vlastimil. > > Could you review or merge this patchset? I hope to review it soon, just "recovering" from a vacation ;-) > It would help to trace compaction behaviour. Yep, Thanks > Thanks. > -- 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: [PATCH 1/3] mm/compaction: enhance trace output to know more about compaction internals
On 01/05/2015 03:33 AM, Joonsoo Kim wrote: On Wed, Dec 03, 2014 at 04:52:05PM +0900, Joonsoo Kim wrote: It'd be useful to know where the both scanner is start. And, it also be useful to know current range where compaction work. It will help to find odd behaviour or problem on compaction. Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com Hello, Andrew and Vlastimil. Could you review or merge this patchset? I hope to review it soon, just recovering from a vacation ;-) It would help to trace compaction behaviour. Yep, Thanks Thanks. -- 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: [PATCH 1/3] mm/compaction: enhance trace output to know more about compaction internals
On Wed, Dec 03, 2014 at 04:52:05PM +0900, Joonsoo Kim wrote: > It'd be useful to know where the both scanner is start. And, it also be > useful to know current range where compaction work. It will help to find > odd behaviour or problem on compaction. > > Signed-off-by: Joonsoo Kim Hello, Andrew and Vlastimil. Could you review or merge this patchset? It would help to trace compaction behaviour. Thanks. -- 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: [PATCH 1/3] mm/compaction: enhance trace output to know more about compaction internals
On Wed, Dec 03, 2014 at 04:52:05PM +0900, Joonsoo Kim wrote: It'd be useful to know where the both scanner is start. And, it also be useful to know current range where compaction work. It will help to find odd behaviour or problem on compaction. Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com Hello, Andrew and Vlastimil. Could you review or merge this patchset? It would help to trace compaction behaviour. Thanks. -- 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/
