On Fri, Aug 9, 2019 at 10:54 AM Mike Kravetz <mike.krav...@oracle.com> wrote: > > (+CC Michal Koutný, cgro...@vger.kernel.org, Aneesh Kumar) > > On 8/8/19 4:13 PM, Mina Almasry wrote: > > Problem: > > Currently tasks attempting to allocate more hugetlb memory than is > > available get > > a failure at mmap/shmget time. This is thanks to Hugetlbfs Reservations [1]. > > However, if a task attempts to allocate hugetlb memory only more than its > > hugetlb_cgroup limit allows, the kernel will allow the mmap/shmget call, > > but will SIGBUS the task when it attempts to fault the memory in. > > > > We have developers interested in using hugetlb_cgroups, and they have > > expressed > > dissatisfaction regarding this behavior. We'd like to improve this > > behavior such that tasks violating the hugetlb_cgroup limits get an error on > > mmap/shmget time, rather than getting SIGBUS'd when they try to fault > > the excess memory in. > > > > The underlying problem is that today's hugetlb_cgroup accounting happens > > at hugetlb memory *fault* time, rather than at *reservation* time. > > Thus, enforcing the hugetlb_cgroup limit only happens at fault time, and > > the offending task gets SIGBUS'd. > > > > Proposed Solution: > > A new page counter named hugetlb.xMB.reservation_[limit|usage]_in_bytes. > > This > > counter has slightly different semantics than > > hugetlb.xMB.[limit|usage]_in_bytes: > > > > - While usage_in_bytes tracks all *faulted* hugetlb memory, > > reservation_usage_in_bytes tracks all *reserved* hugetlb memory. > > > > - If a task attempts to reserve more memory than limit_in_bytes allows, > > the kernel will allow it to do so. But if a task attempts to reserve > > more memory than reservation_limit_in_bytes, the kernel will fail this > > reservation. > > > > This proposal is implemented in this patch, with tests to verify > > functionality and show the usage. > > Thanks for taking on this effort Mina. > No problem! Thanks for reviewing!
> Before looking at the details of the code, it might be helpful to discuss > the expected semantics of the proposed reservation limits. > > I see you took into account the differences between private and shared > mappings. This is good, as the reservation behavior is different for each > of these cases. First let's look at private mappings. > > For private mappings, the reservation usage will be the size of the mapping. > This should be fairly simple. As reservations are consumed in the hugetlbfs > code, reservations in the resv_map are removed. I see you have a hook into > region_del. So, the expectation is that as reservations are consumed the > reservation usage will drop for the cgroup. Correct? I assume by 'reservations are consumed' you mean when a reservation goes from just 'reserved' to actually in use (as in the task is writing to the hugetlb page or something). If so, then the answer is no, that is not correct. When reservations are consumed, the reservation usage stays the same. I.e. the reservation usage tracks hugetlb memory (reserved + used) you could say. This is 100% the intention, as we want to know on mmap time if there is enough 'free' (that is unreserved and unused) memory left over in the cgroup to satisfy the mmap call. The hooks in region_add and region_del are to account shared mappings only. There is a check in those code blocks that makes sure the code is only engaged in shared mappings. The commit messages of patches 3/5 and 4/5 go into more details regarding this. > The only tricky thing about private mappings is COW because of fork. Current > reservation semantics specify that all reservations stay with the parent. > If child faults and can not get page, SIGBUS. I assume the new reservation > limits will work the same. > Although I did not explicitly try it, yes. It should work the same. The additional reservation due to the COW will get charged to whatever cgroup the fork is in. If the task can't get a page it gets SIGBUS'd. If there is not enough room to charge the cgroup it's in, then the charge will fail, which I assume will trigger error path that also leads to SIGBUS. > I believe tracking reservations for shared mappings can get quite complicated. > The hugetlbfs reservation code around shared mappings 'works' on the basis > that shared mapping reservations are global. As a result, reservations are > more associated with the inode than with the task making the reservation. FWIW, I found it not too bad. And my tests at least don't detect an anomaly around shared mappings. The key I think is that I'm tracking cgroup to uncharge on the file_region entry inside the resv_map, so we know who allocated each file_region entry exactly and we can uncharge them when the entry is region_del'd. > For example, consider a file of size 4 hugetlb pages. > Task A maps the first 2 pages, and 2 reservations are taken. Task B maps > all 4 pages, and 2 additional reservations are taken. I am not really sure > of the desired semantics here for reservation limits if A and B are in > separate > cgroups. Should B be charged for 4 or 2 reservations? Task A's cgroup is charged 2 pages to its reservation usage. Task B's cgroup is charged 2 pages to its reservation usage. This is analogous to how shared memory accounting is done for things like tmpfs, and I see no strong reason right now to deviate. I.e. the task that made the reservation is charged with it, and others use it without getting charged. > Also in the example above, after both tasks create their mappings suppose > Task B faults in the first page. Does the reservation usage of Task A go > down as it originally had the reservation? > Reservation usage never goes down when pages are consumed. Yes, I would have this problem if I was planning to decrement reservation usage when pages are put into use, but, the goal is to find out if there is 'free' memory (unreserved + unused) in the cgroup at mmap time, so we want a counter that tracks (reserved + used). > It should also be noted that when hugetlbfs reservations are 'consumed' for > shared mappings there are no changes to the resv_map. Rather the unmap code > compares the contents of the page cache to the resv_map to determine how > many reservations were actually consumed. I did not look close enough to > determine the code drops reservation usage counts as pages are added to shared > mappings. I think this concern also goes away if reservation usage doesn't go down when pages are consumed, but let me know if you still have doubts. Thanks for taking a look so far! > > -- > Mike Kravetz
