Thread (47 messages) 47 messages, 5 authors, 2012-10-30

Re: [PATCH v5 04/18] slab: don't preemptively remove element from list in cache destroy

From: Glauber Costa <hidden>
Date: 2012-10-24 08:19:23
Also in: linux-mm, lkml

On 10/24/2012 10:54 AM, Pekka Enberg wrote:
On Mon, Oct 22, 2012 at 11:40 AM, Glauber Costa [off-list ref] wrote:
quoted
On 10/19/2012 11:34 PM, Christoph Lameter wrote:
quoted
On Fri, 19 Oct 2012, Glauber Costa wrote:
quoted
I, however, see no reason why we need to do so, since we are now locked
during the whole deletion (which wasn't necessarily true before).  I
propose a simplification in which we delete it only when there is no
more going back, so we don't need to add it again.
Ok lets hope that holding the lock does not cause issues.

Acked-by: Christoph Lameter <redacted>
BTW: One of the good things about this set, is that we are naturally
exercising cache destruction a lot more than we did before. So if there
is any problem, either with this or anything related to cache
destruction, it should at least show up a lot more frequently. So far,
this does not seem to cause any problems.
We no longer hold the mutex the whole time after. See commit 210ed9d
("mm, slab: release slab_mutex earlier in kmem_cache_destroy()") for
details.
I will resubmit then.

It doesn't really change the spirit of the patch. I took a look at that
fix, and what it does, is it releases the mutex right after
kmem_cache_shutdown() succeeds. Removing from the list in there would do
the trick.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help