Messages in this thread | | | Date | Fri, 22 Mar 2019 17:47:18 +0000 | From | Christopher Lameter <> | Subject | Re: [PATCH 1/4] mm: Implement kmem objects freeing queue |
| |
On Thu, 21 Mar 2019, Waiman Long wrote:
> When releasing kernel data structures, freeing up the memory > occupied by those objects is usually the last step. To avoid races, > the release operation is commonly done with a lock held. However, the > freeing operations do not need to be under lock, but are in many cases. > > In some complex cases where the locks protect many different memory > objects, that can be a problem especially if some memory debugging > features like KASAN are enabled. In those cases, freeing memory objects > under lock can greatly lengthen the lock hold time. This can even lead > to soft/hard lockups in some extreme cases. > > To make it easer to defer freeing memory objects until after unlock, > a kernel memory freeing queue mechanism is now added. It is modelled > after the wake_q mechanism for waking up tasks without holding a lock.
It is already pretty easy. You just store the pointer to the slab object in a local variable, finish all the unlocks and then free the objects. This is done in numerous places of the kernel.
I fear that the automated mechanism will make the code more difficult to read and result in a loss of clarity of the sequencing of events in releasing locks and objects.
Also there is already kfree_rcu which does a similar thing to what you are proposing here and is used in numerous places.
| |