lkml.org 
[lkml]   [2006]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [robust-futex-4] futex: robust futex support
Date
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

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2006-01-20 22:01    [W:0.131 / U:1.796 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site