diff for duplicates of <5579DFBA.80809@akamai.com> diff --git a/a/1.txt b/N1/1.txt index 94b20ab..fef5a89 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -103,9 +103,3 @@ dDMyibNIRJMX6SeYNIRni40Eafon5h21I95/yWxUaq0FGBZ1NuuSTofxAA53wJJz f0FUI7f53Oxk9EKk8nfg =gfVJ -----END PGP SIGNATURE----- - --- -To unsubscribe, send a message with 'unsubscribe linux-mm' in -the body to majordomo@kvack.org. For more info on Linux MM, -see: http://www.linux-mm.org/ . -Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N1/content_digest index 58957bd..6da7413 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -123,12 +123,6 @@ "dDMyibNIRJMX6SeYNIRni40Eafon5h21I95/yWxUaq0FGBZ1NuuSTofxAA53wJJz\n" "f0FUI7f53Oxk9EKk8nfg\n" "=gfVJ\n" - "-----END PGP SIGNATURE-----\n" - "\n" - "--\n" - "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" - "the body to majordomo@kvack.org. For more info on Linux MM,\n" - "see: http://www.linux-mm.org/ .\n" - "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" + -----END PGP SIGNATURE----- -c7285c1083718431526163daefdcc090f01a298177842078c0aa745b7befc9e5 +1c2776e5f5307b2df331eda24b961bb6bb4c0fbcd777fcc3d9749acf89126774
diff --git a/a/1.txt b/N2/1.txt index 94b20ab..b728806 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -4,26 +4,26 @@ Hash: SHA1 On 06/10/2015 05:59 PM, Andrew Morton wrote: > On Wed, 10 Jun 2015 09:26:47 -0400 Eric B Munson > <emunson@akamai.com> wrote: -> +>=20 >> mlock() allows a user to control page out of program memory, but >> this comes at the cost of faulting in the entire mapping when it >> is -> +>=20 > s/mapping/locked area/ Done. -> +>=20 >> allocated. For large mappings where the entire area is not >> necessary this is not ideal. ->> +>>=20 >> This series introduces new flags for mmap() and mlockall() that >> allow a user to specify that the covered are should not be paged >> out, but only after the memory has been used the first time. -> +>=20 > The comparison with MCL_FUTURE is hiding over in the 2/3 changelog. > It's important so let's copy it here. -> +>=20 > : MCL_ONFAULT is preferrable to MCL_FUTURE for the use cases > enumerated : in the previous patch becuase MCL_FUTURE will behave > as if each mapping : was made with MAP_LOCKED, causing the entire @@ -34,37 +34,37 @@ Done. Done -> +>=20 > I *think* it all looks OK. I'd like someone else to go over it > also if poss. -> -> +>=20 +>=20 > I guess the 2/3 changelog should have something like -> +>=20 > : munlockall() will clear MCL_ONFAULT on all vma's in the process's > VM. Done -> +>=20 > It's pretty obvious, but the manpage delta should make this clear > also. Done -> -> +>=20 +>=20 > Also the changelog(s) and manpage delta should explain that > munlock() clears MCL_ONFAULT. Done -> -> And now I'm wondering what happens if userspace does +>=20 +> And now I'm wondering what happens if userspace does=20 > mmap(MAP_LOCKONFAULT) and later does munlock() on just part of > that region. Does the vma get split? Is this tested? Should also > be in the changelogs and manpage. -> +>=20 > Ditto mlockall(MCL_ONFAULT) followed by munlock(). I'm not sure > that even makes sense but the behaviour should be understood and > tested. @@ -73,8 +73,8 @@ I have extended the kselftest for lock-on-fault to try both of these scenarios and they work as expected. The VMA is split and the VM flags are set appropriately for the resulting VMAs. -> -> +>=20 +>=20 > What's missing here is a syscall to set VM_LOCKONFAULT on an > arbitrary range of memory - mlock() for lock-on-fault. It's a > shame that mlock() didn't take a `mode' argument. Perhaps we @@ -101,11 +101,11 @@ oZLmP2RfajZoPojPZ/bI6mj9Ffqf/Ptau+kLQ56G1IuVmQRi4ZgQ9D1+BILXyKHi uycKovcHVffiQ+z1Ama2b4wP1t5yjNdxBH0oV1KMeScCxfyYHPFuDBe36Krjo8FO dDMyibNIRJMX6SeYNIRni40Eafon5h21I95/yWxUaq0FGBZ1NuuSTofxAA53wJJz f0FUI7f53Oxk9EKk8nfg -=gfVJ +=3DgfVJ -----END PGP SIGNATURE----- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . -Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> +Don't email: <a href=3Dmailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N2/content_digest index 58957bd..5bcde5c 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -25,26 +25,26 @@ "On 06/10/2015 05:59 PM, Andrew Morton wrote:\n" "> On Wed, 10 Jun 2015 09:26:47 -0400 Eric B Munson\n" "> <emunson@akamai.com> wrote:\n" - "> \n" + ">=20\n" ">> mlock() allows a user to control page out of program memory, but\n" ">> this comes at the cost of faulting in the entire mapping when it\n" ">> is\n" - "> \n" + ">=20\n" "> s/mapping/locked area/\n" "\n" "Done.\n" "\n" - "> \n" + ">=20\n" ">> allocated. For large mappings where the entire area is not\n" ">> necessary this is not ideal.\n" - ">> \n" + ">>=20\n" ">> This series introduces new flags for mmap() and mlockall() that\n" ">> allow a user to specify that the covered are should not be paged\n" ">> out, but only after the memory has been used the first time.\n" - "> \n" + ">=20\n" "> The comparison with MCL_FUTURE is hiding over in the 2/3 changelog.\n" "> It's important so let's copy it here.\n" - "> \n" + ">=20\n" "> : MCL_ONFAULT is preferrable to MCL_FUTURE for the use cases\n" "> enumerated : in the previous patch becuase MCL_FUTURE will behave\n" "> as if each mapping : was made with MAP_LOCKED, causing the entire\n" @@ -55,37 +55,37 @@ "\n" "Done\n" "\n" - "> \n" + ">=20\n" "> I *think* it all looks OK. I'd like someone else to go over it\n" "> also if poss.\n" - "> \n" - "> \n" + ">=20\n" + ">=20\n" "> I guess the 2/3 changelog should have something like\n" - "> \n" + ">=20\n" "> : munlockall() will clear MCL_ONFAULT on all vma's in the process's\n" "> VM.\n" "\n" "Done\n" "\n" - "> \n" + ">=20\n" "> It's pretty obvious, but the manpage delta should make this clear\n" "> also.\n" "\n" "Done\n" "\n" - "> \n" - "> \n" + ">=20\n" + ">=20\n" "> Also the changelog(s) and manpage delta should explain that\n" "> munlock() clears MCL_ONFAULT.\n" "\n" "Done\n" "\n" - "> \n" - "> And now I'm wondering what happens if userspace does \n" + ">=20\n" + "> And now I'm wondering what happens if userspace does=20\n" "> mmap(MAP_LOCKONFAULT) and later does munlock() on just part of\n" "> that region. Does the vma get split? Is this tested? Should also\n" "> be in the changelogs and manpage.\n" - "> \n" + ">=20\n" "> Ditto mlockall(MCL_ONFAULT) followed by munlock(). I'm not sure\n" "> that even makes sense but the behaviour should be understood and\n" "> tested.\n" @@ -94,8 +94,8 @@ "scenarios and they work as expected. The VMA is split and the VM\n" "flags are set appropriately for the resulting VMAs.\n" "\n" - "> \n" - "> \n" + ">=20\n" + ">=20\n" "> What's missing here is a syscall to set VM_LOCKONFAULT on an\n" "> arbitrary range of memory - mlock() for lock-on-fault. It's a\n" "> shame that mlock() didn't take a `mode' argument. Perhaps we\n" @@ -122,13 +122,13 @@ "uycKovcHVffiQ+z1Ama2b4wP1t5yjNdxBH0oV1KMeScCxfyYHPFuDBe36Krjo8FO\n" "dDMyibNIRJMX6SeYNIRni40Eafon5h21I95/yWxUaq0FGBZ1NuuSTofxAA53wJJz\n" "f0FUI7f53Oxk9EKk8nfg\n" - "=gfVJ\n" + "=3DgfVJ\n" "-----END PGP SIGNATURE-----\n" "\n" "--\n" "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" "the body to majordomo@kvack.org. For more info on Linux MM,\n" "see: http://www.linux-mm.org/ .\n" - "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" + "Don't email: <a href=3Dmailto:\"dont@kvack.org\"> email@kvack.org </a>" -c7285c1083718431526163daefdcc090f01a298177842078c0aa745b7befc9e5 +7671e94d8b8afdf6dda6554ef102d15ecdbc4e6af9457fcd72119bb10e2c9ac7
diff --git a/a/1.txt b/N3/1.txt index 94b20ab..fef5a89 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -103,9 +103,3 @@ dDMyibNIRJMX6SeYNIRni40Eafon5h21I95/yWxUaq0FGBZ1NuuSTofxAA53wJJz f0FUI7f53Oxk9EKk8nfg =gfVJ -----END PGP SIGNATURE----- - --- -To unsubscribe, send a message with 'unsubscribe linux-mm' in -the body to majordomo@kvack.org. For more info on Linux MM, -see: http://www.linux-mm.org/ . -Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N3/content_digest index 58957bd..2ff17a0 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -2,7 +2,7 @@ "ref\020150610145929.b22be8647887ea7091b09ae1@linux-foundation.org\0" "From\0Eric B Munson <emunson@akamai.com>\0" "Subject\0Re: [RESEND PATCH V2 0/3] Allow user to request memory to be locked on page fault\0" - "Date\0Thu, 11 Jun 2015 15:21:30 -0400\0" + "Date\0Thu, 11 Jun 2015 19:21:30 +0000\0" "To\0Andrew Morton <akpm@linux-foundation.org>\0" "Cc\0Shuah Khan <shuahkh@osg.samsung.com>" Michal Hocko <mhocko@suse.cz> @@ -123,12 +123,6 @@ "dDMyibNIRJMX6SeYNIRni40Eafon5h21I95/yWxUaq0FGBZ1NuuSTofxAA53wJJz\n" "f0FUI7f53Oxk9EKk8nfg\n" "=gfVJ\n" - "-----END PGP SIGNATURE-----\n" - "\n" - "--\n" - "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" - "the body to majordomo@kvack.org. For more info on Linux MM,\n" - "see: http://www.linux-mm.org/ .\n" - "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" + -----END PGP SIGNATURE----- -c7285c1083718431526163daefdcc090f01a298177842078c0aa745b7befc9e5 +b1bb92f1ba8a870524fcfccac5711b1223d3085e37434aa0eb9ade09f88e835e
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.