diff for duplicates of <1491697908.7894.3.camel@gmail.com> diff --git a/a/1.txt b/N1/1.txt index aa9176f..cd74539 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,22 +1,22 @@ -On Fri, 2017-04-07 at 16:28 -0400, JA(C)rA'me Glisse wrote: +On Fri, 2017-04-07 at 16:28 -0400, Jérôme Glisse wrote: > This patch serie implement coherent device memory using ZONE_DEVICE > and adds new helper to the HMM framework to support this new kind > of ZONE_DEVICE memory. This is on top of HMM v19 and you can find a > branch here: ->A +> > https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-cdm ->A +> > It needs more special casing as it behaves differently from regular > ZONE_DEVICE (persistent memory). Unlike the unaddressable memory > type added with HMM patchset, the CDM type can be access by CPU. > Because of this any page can be migrated to CDM memory, private > anonymous or share memory (file back or not). ->A +> > It is missing some features like allowing to direct device fault to > directly allocates device memory (intention is to add new fields to > vm_fault struct for this). ->A ->A +> +> > This is mostly un-tested but i am posting now because i believe we > want to start discussion on design consideration. So this differ from > the NUMA approach by adding yet a new type to ZONE_DEVICE with more @@ -24,12 +24,12 @@ On Fri, 2017-04-07 at 16:28 -0400, JA(C)rA'me Glisse wrote: > miss some code-path that might require more special casing (i and > other need to audit mm to make sure that everytime mm is confronted > so such page it behaves as we want). ->A +> > So i believe question is do we want to keep on adding new type to > ZONE_DEVICE and more special casing each of them or is a NUMA like > approach better ? ->A ->A +> +> > My personal belief is that the hierarchy of memory is getting deeper > (DDR, HBM stack memory, persistent memory, device memory, ...) and > it may make sense to try to mirror this complexity within mm concept. @@ -80,7 +80,7 @@ migration (page cache migration), fault handling to the right location (direct page cache allocation in the coherent memory), mlock handling, RSS accounting, memcg enforcement for pages not on LRU, etc. ->A +> > Note that i don't think choosing one would mean we will be stuck with > it, as long as we don't expose anything new (syscall) to userspace > and hide thing through driver API then we keep our options open to @@ -90,19 +90,13 @@ RSS accounting, memcg enforcement for pages not on LRU, etc. I agree, but I think user space will need to adopt, for example using malloc on a coherent device will not work, the user space will need to have a driver supported way of accessing coherent memory. -A + > Nonetheless we need to make progress on this as they are hardware > right around the corner and it would be a shame if we could not > leverage such hardware with linux. ->A +> > -I agree 100%A +I agree 100% Balbir Singh. - --- -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 2086ba8..524c54c 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -15,25 +15,25 @@ " Dan Williams <dan.j.williams@intel.com>\0" "\00:1\0" "b\0" - "On Fri, 2017-04-07 at 16:28 -0400, JA(C)rA'me Glisse wrote:\n" + "On Fri, 2017-04-07 at 16:28 -0400, J\303\251r\303\264me Glisse wrote:\n" "> This patch serie implement coherent device memory using ZONE_DEVICE\n" "> and adds new helper to the HMM framework to support this new kind\n" "> of ZONE_DEVICE memory. This is on top of HMM v19 and you can find a\n" "> branch here:\n" - ">A \n" + ">\302\240\n" "> https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-cdm\n" - ">A \n" + ">\302\240\n" "> It needs more special casing as it behaves differently from regular\n" "> ZONE_DEVICE (persistent memory). Unlike the unaddressable memory\n" "> type added with HMM patchset, the CDM type can be access by CPU.\n" "> Because of this any page can be migrated to CDM memory, private\n" "> anonymous or share memory (file back or not).\n" - ">A \n" + ">\302\240\n" "> It is missing some features like allowing to direct device fault to\n" "> directly allocates device memory (intention is to add new fields to\n" "> vm_fault struct for this).\n" - ">A \n" - ">A \n" + ">\302\240\n" + ">\302\240\n" "> This is mostly un-tested but i am posting now because i believe we\n" "> want to start discussion on design consideration. So this differ from\n" "> the NUMA approach by adding yet a new type to ZONE_DEVICE with more\n" @@ -41,12 +41,12 @@ "> miss some code-path that might require more special casing (i and\n" "> other need to audit mm to make sure that everytime mm is confronted\n" "> so such page it behaves as we want).\n" - ">A \n" + ">\302\240\n" "> So i believe question is do we want to keep on adding new type to\n" "> ZONE_DEVICE and more special casing each of them or is a NUMA like\n" "> approach better ?\n" - ">A \n" - ">A \n" + ">\302\240\n" + ">\302\240\n" "> My personal belief is that the hierarchy of memory is getting deeper\n" "> (DDR, HBM stack memory, persistent memory, device memory, ...) and\n" "> it may make sense to try to mirror this complexity within mm concept.\n" @@ -97,7 +97,7 @@ "(direct page cache allocation in the coherent memory), mlock handling,\n" "RSS accounting, memcg enforcement for pages not on LRU, etc.\n" "\n" - ">A \n" + ">\302\240\n" "> Note that i don't think choosing one would mean we will be stuck with\n" "> it, as long as we don't expose anything new (syscall) to userspace\n" "> and hide thing through driver API then we keep our options open to\n" @@ -107,21 +107,15 @@ "I agree, but I think user space will need to adopt, for example using\n" "malloc on a coherent device will not work, the user space will need to\n" "have a driver supported way of accessing coherent memory.\n" - "A \n" + "\302\240\n" "> Nonetheless we need to make progress on this as they are hardware\n" "> right around the corner and it would be a shame if we could not\n" "> leverage such hardware with linux.\n" - ">A \n" + ">\302\240\n" ">\n" "\n" - "I agree 100%A \n" + "I agree 100%\302\240\n" "\n" - "Balbir Singh.\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>" + Balbir Singh. -67905296f115d666ac3bf7c1d96578309d78cae3e4a01e300a64971eff8a35c3 +9bfaa56b27210e06a8d2ee023ac58a74ec8e7d05cf5e6bce8c9458af11ebc1ba
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.