lkml.org 
[lkml]   [2005]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PI BUG with -rt13

* david singleton <dsingleton@mvista.com> wrote:

> > why is there per-vma info needed?
>
> I've had numerous requests to add support for pthread_mutexes that
> have been 'malloc'd and end up in the heap.
>
> The original robust futex patch only supported shared pthread mutexes,
> backed either by a file in which the pthread mutex was written on in
> anonymous memory allocated via mmap with the MAP_SHARE and
> MAP_ANONYMOUS flags.
>
> Anonymous memory gets backed by an inode on which we lookup and hang
> the robust mutex structure (and which gets freed on the last reference
> to the inode.)
>
> The choice seemed either to back heap with the anonymous memory/inode
> framework or just hang the struct on the vma itself.

putting it into the vma is just about the worst solution. vma size is
something we are very sensitive to. Your patch adds:

+ int robust_init; /* robust initialized? */
+ struct list_head robust_list; /* list of robust futexes in this vma */
+ struct semaphore robust_sem; /* semaphore to protect the list */

which is unacceptable. _And_ you were also talking about making it an
rbtree... why do you want to make it a tree?

also, funky runtime flags like 'robust_init' are just sloppy.

add a separate pointer, and put the above fields into a separate SLAB.
That way the overhead to the vma is a single pointer. (which might still
be unacceptable to upstream!)

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-11-25 09:06    [W:0.065 / U:0.524 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site