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.
I 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.
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.