Le 14/10/2016 à 20:34, Joerg Sonnenberger a écrit :
On Fri, Oct 14, 2016 at 07:22:50PM +0200, Maxime Villard wrote:Le 11/10/2016 à 18:26, Joerg Sonnenberger a écrit :On Tue, Oct 11, 2016 at 02:42:00PM +0200, Maxime Villard wrote:All this to say that in pmap_enter_ma on x86, an optimization is possible. In this function, new_pve and new_sparepve are always allocated, but not always needed. The reason it is done this way is because preemption is disabled in the critical part, so obviously the allocation needs to be performed earlier.What happens if we cache a pair in curcpu? Basically, instead of the pool get, check if curcpu already has one and take that out, at the end, if the pair was unused, put it into curcpu. JoergI see what you mean, but I believe there is a locking issue. Fetching the pointers from curcpu needs to be done with preemption disabled, but if we find out the pointers are NULL then we need to allocate them, and it cannot be done here anymore.Worst case, enter a critical section to get them and exit it. After that, do an allocation if necessary. From your numbers, a good number of instances will not have to do anything. Joerg
But at the end you still need to be in a critical section if you want to put the pointers in curcpu. We exit the critical section, so we reenable preemption and start the allocation. In the meantime, the cpu gets switched to another lwp, which too sees there is no pointer available in curcpu, and it therefore allocates these pointers and puts them in curcpu at the end. Then the cpu goes back the original lwp, allocates the two pointers, reenters a critical section, wants to put these into curcpu; but they are already here now. We would either be leaking memory or freeing some we allocated for no reason, the latter meaning we still didn't fix the issue for real. I'm not sure multiplying critical sections is a good idea.