Wiadomość napisana przez Alan Cox <a...@rice.edu> w dniu 30 lip 2013, o godz. 19:40: > On Jul 21, 2013, at 2:50 PM, Jeremie Le Hen wrote: >> >>> Also, a wired mapping can be destroyed by calling munmap(2) without >>> first calling munlock(2), in which case, RACCT_MEMLOCK will be >>> incorrect. >> >> So I think the right way to tackle this is to handle racct in the vm >> layer rather than at the syscall layer. >> > > The VM system already maintains counters equivalent to RACCT_VMEM and > RACCT_MEMLOCK. They are "map->size" and "pmap_wired_count(map->pmap)". > Instead of maintaining duplicate counters, could the resource accounting > framework be extended to support callbacks to obtain a value when it's > actually needed?
That would be rather hard. The way this works is that raccts are hierarchical, and every time resource allocation is done, its respective counter needs to be propagated all the way up. If it hits a limit somewhere, the racct function returns error meaning the resource allocation was denied. In other words, racct wants to know when the counter changes. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
