On 06/02/2020 08:22 PM, Daniel Jordan wrote:
> On Mon, Jun 01, 2020 at 09:48:09PM -0700, John Hubbard wrote:
>> However, the fact that this is under discussion hints at the need for a
>> bit of documentation help. What do you think about adding some notes about
>> all of this to, say, Documentation/vm/page_migration.rst ?
>
> Yes, that would be good. I understand the intent better now but still think
> the 'failure' event could be misinterpreted as outright failure instead of
> splitting followed by successfully moving the constituent pages.
Does this look okay and sufficient ?
--- a/Documentation/vm/page_migration.rst
+++ b/Documentation/vm/page_migration.rst
@@ -253,5 +253,20 @@ which are function pointers of struct address_space_operations.
PG_isolated is alias with PG_reclaim flag so driver shouldn't use the flag
for own purpose.
+Quantifying Migration
+=====================
+Following events can be used to quantify page migration.
+
+- PGMIGRATE_SUCCESS
+- PGMIGRATE_FAIL
+- THP_MIGRATION_SUCCESS
+- THP_MIGRATION_FAILURE
+
+THP_MIGRATION_FAILURE in particular represents an event when a THP could not be
+migrated as a single entity following an allocation failure and ended up getting
+split into constituent normal pages before being retried. This event, along with
+PGMIGRATE_SUCCESS and PGMIGRATE_FAIL will help in quantifying and analyzing THP
+migration events including both success and failure cases.
+
>
> It might help to clarify in the changelog as well.
>
Sure, will update the commit message accordingly.
