On Wed, Jul 5, 2017 at 4:38 PM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > On Wed 05-07-17 13:18:18, Balbir Singh wrote: >> On Tue, Jul 4, 2017 at 10:51 PM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: >> > On Mon 03-07-17 17:14:14, Jérôme Glisse wrote: >> >> HMM pages (private or public device pages) are ZONE_DEVICE page and >> >> thus you can not use page->lru fields of those pages. This patch >> >> re-arrange the uncharge to allow single page to be uncharge without >> >> modifying the lru field of the struct page. >> >> >> >> There is no change to memcontrol logic, it is the same as it was >> >> before this patch. >> > >> > What is the memcg semantic of the memory? Why is it even charged? AFAIR >> > this is not a reclaimable memory. If yes how are we going to deal with >> > memory limits? What should happen if go OOM? Does killing an process >> > actually help to release that memory? Isn't it pinned by a device? >> > >> > For the patch itself. It is quite ugly but I haven't spotted anything >> > obviously wrong with it. It is the memcg semantic with this class of >> > memory which makes me worried. >> > >> >> This is the HMM CDM case. Memory is normally malloc'd and then >> migrated to ZONE_DEVICE or vice-versa. One of the things we did >> discuss was seeing ZONE_DEVICE memory in user page tables. > > This doesn't answer any of the above questions though. Jerome is the expert and I am sure he has a better answer, but my understanding is that this path gets called through release_pages() <-- zap_pte_range(). At first even I pondered about the same thing, but then came across this path. Balbir Singh. -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
