On Thursday 19 January 2006 06:22, Andrew Morton wrote:
> david singleton <dsingleton@mvista.com> wrote:
> > +	if (mapping->robust_head == NULL)
> > +		return;
> > +
> > +	if (list_empty(&mapping->robust_head->robust_list))
> > +		return;
> > +
> > +	mutex_lock(&mapping->robust_head->robust_mutex);
> > +
> > +	head = &mapping->robust_head->robust_list;
> > +	futex_head = mapping->robust_head;
> > +
> > +	list_for_each_entry_safe(this, next, head, list) {
> > +		list_del(&this->list);
> > +		kmem_cache_free(robust_futex_cachep, this);
> > +	}
> 
> If we're throwing away the entire contents of the list, there's no need to
> detach items as we go.
 
Couldn't even detach the list elements first by

list_splice_init(&mapping->robust_head->robust_list, head);

and free the list from "head" after releasing the mutex? 
This would reduce lock contention, no?

> > +#ifdef CONFIG_ROBUST_FUTEX
> > +	robust_futex_cachep = kmem_cache_create("robust_futex", sizeof(struct futex_robust), 0, 0, NULL, NULL);
> > +	file_futex_cachep = kmem_cache_create("file_futex", sizeof(struct futex_head), 0, 0, NULL, NULL);
> > +#endif
> 
> A bit of 80-column wrapping needed there please.
> 
> Are futex_heads likely to be allocated in sufficient volume to justify
> their own slab cache, rather than using kmalloc()?  The speed is the same -
> if anything, kmalloc() will be faster because its text and data are more
> likely to be in CPU cache.
 
The goal here was to do cheap futex accounting, as described in the 
documentation to this patch.


Regards

Ingo Oeser