> Date: Thu, 19 Oct 2017 13:16:09 -0700 > From: Chuck Silvers <[email protected]> > > this latest patch sounds like a definite improvement to me.
kern_exec rev. 1.448 > as I recall, the original pre-pool exec_map code would free the > physical args pages as part of freeing the kernel virtual space... > if we're still using a pool here, will the pool cache all this? > it would be nice to avoid ever paging exec args pages out to swap space. > maybe we could mark the execargs pages as clean before freeing the > execargs mapping back to the pool? this is a minor issue compared to > the current problem, I'd say proceed with your current patch for now > and we can add any further refinements later. With the correctness now addressed (I hope!), I will leave the task of adding calls to uvm_map_clean(PGO_FREE) just before pool_put, and testing what effects they have on performance in contrast to the uvm_km_free calls that ad@ was trying to avoid in the first place, as an exercise for a reader more dedicated to performance than I. I, meanwhile, will be quietly disappointed in myself for having taken six years to analyze and fix this bug, which is more than half the time it has been around and nearly the entire time it has been in a release! (In my defence, I was pursuing other endeavours during those six years as well.)
