[PATCH 4/5] hmm: heterogeneous memory management v6
From: Jérôme Glisse Motivation: Heterogeneous memory management is intended to allow a device to transparently access a process address space without having to lock pages of the process or take references on them. In other word mirroring a process address space while allowing the regular memory management event such as page reclamation or page migration, to happen seamlessly. Recent years have seen a surge into the number of specialized devices that are part of a computer platform (from desktop to phone). So far each of those devices have operated on there own private address space that is not link or expose to the process address space that is using them. This separation often leads to multiple memory copy happening between the device owned memory and the process memory. This of course is both a waste of cpu cycle and memory. Over the last few years most of those devices have gained a full mmu allowing them to support multiple page table, page fault and other features that are found inside cpu mmu. There is now a strong incentive to start leveraging capabilities of such devices and to start sharing process address to avoid any unnecessary memory copy as well as simplifying the programming model of those devices by sharing an unique and common address space with the process that use them. The aim of the heterogeneous memory management is to provide a common API that can be use by any such devices in order to mirror process address. The hmm code provide an unique entry point and interface itself with the core mm code of the linux kernel avoiding duplicate implementation and shielding device driver code from core mm code. Moreover, hmm also intend to provide support for migrating memory to device private memory, allowing device to work on its own fast local memory. The hmm code would be responsible to intercept cpu page fault on migrated range and to migrate it back to system memory allowing cpu to resume its access to the memory. Another feature hmm intend to provide is support for atomic operation for the device even if the bus linking the device and the cpu do not have any such capabilities. On such hardware atomic operation require the page to only be mapped on the device or on the cpu but not both at the same time. We expect that graphic processing unit and network interface to be among the first users of such api. Hardware requirement: Because hmm is intended to be use by device driver there are minimum features requirement for the hardware mmu : - hardware have its own page table per process (can be share btw != devices) - hardware mmu support page fault and suspend execution until the page fault is serviced by hmm code. The page fault must also trigger some form of interrupt so that hmm code can be call by the device driver. - hardware must support at least read only mapping (otherwise it can not access read only range of the process address space). - hardware access to system memory must be cache coherent with the cpu. For better memory management it is highly recommanded that the device also support the following features : - hardware mmu set access bit in its page table on memory access (like cpu). - hardware page table can be updated from cpu or through a fast path. - hardware provide advanced statistic over which range of memory it access the most. - hardware differentiate atomic memory access from regular access allowing to support atomic operation even on platform that do not have atomic support on the bus linking the device with the cpu. Implementation: The hmm layer provide a simple API to the device driver. Each device driver have to register and hmm device that holds pointer to all the callback the hmm code will make to synchronize the device page table with the cpu page table of a given process. For each process it wants to mirror the device driver must register a mirror hmm structure that holds all the informations specific to the process being mirrored. Each hmm mirror uniquely link an hmm device with a process address space (the mm struct). This design allow several different device driver to mirror concurrently the same process. The hmm layer will dispatch approprietly to each device driver modification that are happening to the process address space. The hmm layer rely on the mmu notifier api to monitor change to the process address space. Because update to device page table can have unbound completion time, the hmm layer need the capability to sleep during mmu notifier callback. This patch only implement the core of the hmm layer and do not support feature such as migration to device memory. Changed since v1: - convert fence to refcounted object - change the api to provide pte value directly avoiding useless temporary special hmm pfn value - cleanups & fixes ... Changed since v2: - fixed checkpatch.pl warnings & errors - converted to a staging feature Changed since v3: - Use mmput notifier chain instead of
[PATCH 4/5] hmm: heterogeneous memory management v6
From: Jérôme Glisse jgli...@redhat.com Motivation: Heterogeneous memory management is intended to allow a device to transparently access a process address space without having to lock pages of the process or take references on them. In other word mirroring a process address space while allowing the regular memory management event such as page reclamation or page migration, to happen seamlessly. Recent years have seen a surge into the number of specialized devices that are part of a computer platform (from desktop to phone). So far each of those devices have operated on there own private address space that is not link or expose to the process address space that is using them. This separation often leads to multiple memory copy happening between the device owned memory and the process memory. This of course is both a waste of cpu cycle and memory. Over the last few years most of those devices have gained a full mmu allowing them to support multiple page table, page fault and other features that are found inside cpu mmu. There is now a strong incentive to start leveraging capabilities of such devices and to start sharing process address to avoid any unnecessary memory copy as well as simplifying the programming model of those devices by sharing an unique and common address space with the process that use them. The aim of the heterogeneous memory management is to provide a common API that can be use by any such devices in order to mirror process address. The hmm code provide an unique entry point and interface itself with the core mm code of the linux kernel avoiding duplicate implementation and shielding device driver code from core mm code. Moreover, hmm also intend to provide support for migrating memory to device private memory, allowing device to work on its own fast local memory. The hmm code would be responsible to intercept cpu page fault on migrated range and to migrate it back to system memory allowing cpu to resume its access to the memory. Another feature hmm intend to provide is support for atomic operation for the device even if the bus linking the device and the cpu do not have any such capabilities. On such hardware atomic operation require the page to only be mapped on the device or on the cpu but not both at the same time. We expect that graphic processing unit and network interface to be among the first users of such api. Hardware requirement: Because hmm is intended to be use by device driver there are minimum features requirement for the hardware mmu : - hardware have its own page table per process (can be share btw != devices) - hardware mmu support page fault and suspend execution until the page fault is serviced by hmm code. The page fault must also trigger some form of interrupt so that hmm code can be call by the device driver. - hardware must support at least read only mapping (otherwise it can not access read only range of the process address space). - hardware access to system memory must be cache coherent with the cpu. For better memory management it is highly recommanded that the device also support the following features : - hardware mmu set access bit in its page table on memory access (like cpu). - hardware page table can be updated from cpu or through a fast path. - hardware provide advanced statistic over which range of memory it access the most. - hardware differentiate atomic memory access from regular access allowing to support atomic operation even on platform that do not have atomic support on the bus linking the device with the cpu. Implementation: The hmm layer provide a simple API to the device driver. Each device driver have to register and hmm device that holds pointer to all the callback the hmm code will make to synchronize the device page table with the cpu page table of a given process. For each process it wants to mirror the device driver must register a mirror hmm structure that holds all the informations specific to the process being mirrored. Each hmm mirror uniquely link an hmm device with a process address space (the mm struct). This design allow several different device driver to mirror concurrently the same process. The hmm layer will dispatch approprietly to each device driver modification that are happening to the process address space. The hmm layer rely on the mmu notifier api to monitor change to the process address space. Because update to device page table can have unbound completion time, the hmm layer need the capability to sleep during mmu notifier callback. This patch only implement the core of the hmm layer and do not support feature such as migration to device memory. Changed since v1: - convert fence to refcounted object - change the api to provide pte value directly avoiding useless temporary special hmm pfn value - cleanups fixes ... Changed since v2: - fixed checkpatch.pl warnings errors - converted to a staging feature Changed since v3: - Use mmput notifier
Re: [PATCH 4/5] hmm: heterogeneous memory management v6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/03/2014 03:42 PM, j.gli...@gmail.com wrote: > From: Jérôme Glisse > > Motivation: > > Heterogeneous memory management is intended to allow a device to > transparently access a process address space without having to lock > pages of the process or take references on them. In other word > mirroring a process address space while allowing the regular memory > management event such as page reclamation or page migration, to > happen seamlessly. > > Recent years have seen a surge into the number of specialized > devices that are part of a computer platform (from desktop to > phone). So far each of those devices have operated on there own > private address space that is not link or expose to the process > address space that is using them. This separation often leads to > multiple memory copy happening between the device owned memory and > the process memory. This of course is both a waste of cpu cycle and > memory. > > Over the last few years most of those devices have gained a full > mmu allowing them to support multiple page table, page fault and > other features that are found inside cpu mmu. There is now a strong > incentive to start leveraging capabilities of such devices and to > start sharing process address to avoid any unnecessary memory copy > as well as simplifying the programming model of those devices by > sharing an unique and common address space with the process that > use them. > > The aim of the heterogeneous memory management is to provide a > common API that can be use by any such devices in order to mirror > process address. The hmm code provide an unique entry point and > interface itself with the core mm code of the linux kernel avoiding > duplicate implementation and shielding device driver code from core > mm code. Acked-by: Rik van Riel - -- All rights reversed -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUXTs9AAoJEM553pKExN6DhSYIAI41vr6c/vVdIg2m6Wq3DiSS KtBTUX5/cFmvh9Zd3S422ZwzJQ6ZZLGsNuh2LajLqR0dhDKkwxS7FWFSdifcAfq2 B/Xq8JyeW98Fa0OP0V4uqMuo1FMvlXFZsDijFefxo5F2T/H6XyRI2M+f4w5w9iZa 3EvUaFHoG+mCjoR+ANuxwR9J048wWF626R6CHPOvvIKDNRVr+LADvLMBXmbnrYJs 643mmjhNT+EdPQbxBVszsUbBo/mGicRBuW+t3XkWy1g+hsa4AewhHnOuSHDr13zM YBFjeGP1TbOQxtkiJetsAE4pKxSlJDoscp7vbJjYzLz3Kk2Fag3r1kpSU8S8stI= =ucI+ -END PGP SIGNATURE- -- 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 4/5] hmm: heterogeneous memory management v6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/03/2014 03:42 PM, j.gli...@gmail.com wrote: From: Jérôme Glisse jgli...@redhat.com Motivation: Heterogeneous memory management is intended to allow a device to transparently access a process address space without having to lock pages of the process or take references on them. In other word mirroring a process address space while allowing the regular memory management event such as page reclamation or page migration, to happen seamlessly. Recent years have seen a surge into the number of specialized devices that are part of a computer platform (from desktop to phone). So far each of those devices have operated on there own private address space that is not link or expose to the process address space that is using them. This separation often leads to multiple memory copy happening between the device owned memory and the process memory. This of course is both a waste of cpu cycle and memory. Over the last few years most of those devices have gained a full mmu allowing them to support multiple page table, page fault and other features that are found inside cpu mmu. There is now a strong incentive to start leveraging capabilities of such devices and to start sharing process address to avoid any unnecessary memory copy as well as simplifying the programming model of those devices by sharing an unique and common address space with the process that use them. The aim of the heterogeneous memory management is to provide a common API that can be use by any such devices in order to mirror process address. The hmm code provide an unique entry point and interface itself with the core mm code of the linux kernel avoiding duplicate implementation and shielding device driver code from core mm code. Acked-by: Rik van Riel r...@redhat.com - -- All rights reversed -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUXTs9AAoJEM553pKExN6DhSYIAI41vr6c/vVdIg2m6Wq3DiSS KtBTUX5/cFmvh9Zd3S422ZwzJQ6ZZLGsNuh2LajLqR0dhDKkwxS7FWFSdifcAfq2 B/Xq8JyeW98Fa0OP0V4uqMuo1FMvlXFZsDijFefxo5F2T/H6XyRI2M+f4w5w9iZa 3EvUaFHoG+mCjoR+ANuxwR9J048wWF626R6CHPOvvIKDNRVr+LADvLMBXmbnrYJs 643mmjhNT+EdPQbxBVszsUbBo/mGicRBuW+t3XkWy1g+hsa4AewhHnOuSHDr13zM YBFjeGP1TbOQxtkiJetsAE4pKxSlJDoscp7vbJjYzLz3Kk2Fag3r1kpSU8S8stI= =ucI+ -END PGP SIGNATURE- -- 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/
[PATCH 4/5] hmm: heterogeneous memory management v6
From: Jérôme Glisse Motivation: Heterogeneous memory management is intended to allow a device to transparently access a process address space without having to lock pages of the process or take references on them. In other word mirroring a process address space while allowing the regular memory management event such as page reclamation or page migration, to happen seamlessly. Recent years have seen a surge into the number of specialized devices that are part of a computer platform (from desktop to phone). So far each of those devices have operated on there own private address space that is not link or expose to the process address space that is using them. This separation often leads to multiple memory copy happening between the device owned memory and the process memory. This of course is both a waste of cpu cycle and memory. Over the last few years most of those devices have gained a full mmu allowing them to support multiple page table, page fault and other features that are found inside cpu mmu. There is now a strong incentive to start leveraging capabilities of such devices and to start sharing process address to avoid any unnecessary memory copy as well as simplifying the programming model of those devices by sharing an unique and common address space with the process that use them. The aim of the heterogeneous memory management is to provide a common API that can be use by any such devices in order to mirror process address. The hmm code provide an unique entry point and interface itself with the core mm code of the linux kernel avoiding duplicate implementation and shielding device driver code from core mm code. Moreover, hmm also intend to provide support for migrating memory to device private memory, allowing device to work on its own fast local memory. The hmm code would be responsible to intercept cpu page fault on migrated range and to migrate it back to system memory allowing cpu to resume its access to the memory. Another feature hmm intend to provide is support for atomic operation for the device even if the bus linking the device and the cpu do not have any such capabilities. On such hardware atomic operation require the page to only be mapped on the device or on the cpu but not both at the same time. We expect that graphic processing unit and network interface to be among the first users of such api. Hardware requirement: Because hmm is intended to be use by device driver there are minimum features requirement for the hardware mmu : - hardware have its own page table per process (can be share btw != devices) - hardware mmu support page fault and suspend execution until the page fault is serviced by hmm code. The page fault must also trigger some form of interrupt so that hmm code can be call by the device driver. - hardware must support at least read only mapping (otherwise it can not access read only range of the process address space). - hardware access to system memory must be cache coherent with the cpu. For better memory management it is highly recommanded that the device also support the following features : - hardware mmu set access bit in its page table on memory access (like cpu). - hardware page table can be updated from cpu or through a fast path. - hardware provide advanced statistic over which range of memory it access the most. - hardware differentiate atomic memory access from regular access allowing to support atomic operation even on platform that do not have atomic support on the bus linking the device with the cpu. Implementation: The hmm layer provide a simple API to the device driver. Each device driver have to register and hmm device that holds pointer to all the callback the hmm code will make to synchronize the device page table with the cpu page table of a given process. For each process it wants to mirror the device driver must register a mirror hmm structure that holds all the informations specific to the process being mirrored. Each hmm mirror uniquely link an hmm device with a process address space (the mm struct). This design allow several different device driver to mirror concurrently the same process. The hmm layer will dispatch approprietly to each device driver modification that are happening to the process address space. The hmm layer rely on the mmu notifier api to monitor change to the process address space. Because update to device page table can have unbound completion time, the hmm layer need the capability to sleep during mmu notifier callback. This patch only implement the core of the hmm layer and do not support feature such as migration to device memory. Changed since v1: - convert fence to refcounted object - change the api to provide pte value directly avoiding useless temporary special hmm pfn value - cleanups & fixes ... Changed since v2: - fixed checkpatch.pl warnings & errors - converted to a staging feature Changed since v3: - Use mmput notifier chain instead of
[PATCH 4/5] hmm: heterogeneous memory management v6
From: Jérôme Glisse jgli...@redhat.com Motivation: Heterogeneous memory management is intended to allow a device to transparently access a process address space without having to lock pages of the process or take references on them. In other word mirroring a process address space while allowing the regular memory management event such as page reclamation or page migration, to happen seamlessly. Recent years have seen a surge into the number of specialized devices that are part of a computer platform (from desktop to phone). So far each of those devices have operated on there own private address space that is not link or expose to the process address space that is using them. This separation often leads to multiple memory copy happening between the device owned memory and the process memory. This of course is both a waste of cpu cycle and memory. Over the last few years most of those devices have gained a full mmu allowing them to support multiple page table, page fault and other features that are found inside cpu mmu. There is now a strong incentive to start leveraging capabilities of such devices and to start sharing process address to avoid any unnecessary memory copy as well as simplifying the programming model of those devices by sharing an unique and common address space with the process that use them. The aim of the heterogeneous memory management is to provide a common API that can be use by any such devices in order to mirror process address. The hmm code provide an unique entry point and interface itself with the core mm code of the linux kernel avoiding duplicate implementation and shielding device driver code from core mm code. Moreover, hmm also intend to provide support for migrating memory to device private memory, allowing device to work on its own fast local memory. The hmm code would be responsible to intercept cpu page fault on migrated range and to migrate it back to system memory allowing cpu to resume its access to the memory. Another feature hmm intend to provide is support for atomic operation for the device even if the bus linking the device and the cpu do not have any such capabilities. On such hardware atomic operation require the page to only be mapped on the device or on the cpu but not both at the same time. We expect that graphic processing unit and network interface to be among the first users of such api. Hardware requirement: Because hmm is intended to be use by device driver there are minimum features requirement for the hardware mmu : - hardware have its own page table per process (can be share btw != devices) - hardware mmu support page fault and suspend execution until the page fault is serviced by hmm code. The page fault must also trigger some form of interrupt so that hmm code can be call by the device driver. - hardware must support at least read only mapping (otherwise it can not access read only range of the process address space). - hardware access to system memory must be cache coherent with the cpu. For better memory management it is highly recommanded that the device also support the following features : - hardware mmu set access bit in its page table on memory access (like cpu). - hardware page table can be updated from cpu or through a fast path. - hardware provide advanced statistic over which range of memory it access the most. - hardware differentiate atomic memory access from regular access allowing to support atomic operation even on platform that do not have atomic support on the bus linking the device with the cpu. Implementation: The hmm layer provide a simple API to the device driver. Each device driver have to register and hmm device that holds pointer to all the callback the hmm code will make to synchronize the device page table with the cpu page table of a given process. For each process it wants to mirror the device driver must register a mirror hmm structure that holds all the informations specific to the process being mirrored. Each hmm mirror uniquely link an hmm device with a process address space (the mm struct). This design allow several different device driver to mirror concurrently the same process. The hmm layer will dispatch approprietly to each device driver modification that are happening to the process address space. The hmm layer rely on the mmu notifier api to monitor change to the process address space. Because update to device page table can have unbound completion time, the hmm layer need the capability to sleep during mmu notifier callback. This patch only implement the core of the hmm layer and do not support feature such as migration to device memory. Changed since v1: - convert fence to refcounted object - change the api to provide pte value directly avoiding useless temporary special hmm pfn value - cleanups fixes ... Changed since v2: - fixed checkpatch.pl warnings errors - converted to a staging feature Changed since v3: - Use mmput notifier
