On Thu, Apr 9, 2015 at 10:12 AM, Linus Torvalds
wrote:
>
> It's just unusual, which I think makes it slightly harder to read for
> a *human* just because it breaks the normal pattern of those things.
> But there's nothing technically wrong with it.
You could have written it as
static
On Thu, Apr 9, 2015 at 9:59 AM, Peter Zijlstra wrote:
>
> I was a little surprised myself it worked, but its a constant after
> all so it 'should'.
Well, it should actually work for non-constants too, even when that
'idx' isn't inlined to one of the fixed constants. So even if this
will ever hit
On Thu, Apr 09, 2015 at 09:31:16AM -0700, Linus Torvalds wrote:
> On Thu, Apr 9, 2015 at 5:13 AM, Peter Zijlstra wrote:
> >
> > struct latch_tree_node {
> > + struct rb_node node[2];
> > };
> >
> > +static __always_inline struct latch_tree_node *
> > +__lt_from_rb(struct rb_node *node,
On Thu, Apr 9, 2015 at 5:13 AM, Peter Zijlstra wrote:
>
> struct latch_tree_node {
> + struct rb_node node[2];
> };
>
> +static __always_inline struct latch_tree_node *
> +__lt_from_rb(struct rb_node *node, int idx)
> +{
> + return container_of(node, struct latch_tree_node,
On Thu, Apr 09, 2015 at 02:13:36PM +0200, Peter Zijlstra wrote:
> +struct module;
> +
> +struct mod_tree_node {
> + struct latch_tree_node node;
> + struct module *mod;
> +};
The module pointer should be first in this structure.
--
To unsubscribe from this list: send the line "unsubscribe
On Thu, Apr 09, 2015 at 04:55:05PM +0800, Lai Jiangshan wrote:
> This sentence is talking about module.c not latch_tree.h. So I guess
> it is user(module.c)'s problem, not latch_tree.h's problem.
>
> The user(module.c) can wrap the struct latch_tree_nodes and add @priv.
OK, took me a while to
On 04/09/2015 04:14 PM, Peter Zijlstra wrote:
> On Thu, Apr 09, 2015 at 04:09:07PM +0800, Lai Jiangshan wrote:
>> On 04/09/2015 12:48 AM, Peter Zijlstra wrote:
>>
>>> +
>>> +struct latch_tree_node {
>>> + /*
>>> +* Because we have an array of two entries in struct latch_tree_nodes
>>> +*
On Thu, Apr 09, 2015 at 04:09:07PM +0800, Lai Jiangshan wrote:
> On 04/09/2015 12:48 AM, Peter Zijlstra wrote:
>
> > +
> > +struct latch_tree_node {
> > + /*
> > +* Because we have an array of two entries in struct latch_tree_nodes
> > +* it's not possible to use container_of() to get
On 04/09/2015 12:48 AM, Peter Zijlstra wrote:
> +
> +struct latch_tree_node {
> + /*
> + * Because we have an array of two entries in struct latch_tree_nodes
> + * it's not possible to use container_of() to get back to the
> + * encapsulating structure; therefore we have to put
On Thu, Apr 09, 2015 at 09:31:16AM -0700, Linus Torvalds wrote:
On Thu, Apr 9, 2015 at 5:13 AM, Peter Zijlstra pet...@infradead.org wrote:
struct latch_tree_node {
+ struct rb_node node[2];
};
+static __always_inline struct latch_tree_node *
+__lt_from_rb(struct rb_node
On 04/09/2015 04:14 PM, Peter Zijlstra wrote:
On Thu, Apr 09, 2015 at 04:09:07PM +0800, Lai Jiangshan wrote:
On 04/09/2015 12:48 AM, Peter Zijlstra wrote:
+
+struct latch_tree_node {
+ /*
+* Because we have an array of two entries in struct latch_tree_nodes
+* it's not possible
On Thu, Apr 09, 2015 at 02:13:36PM +0200, Peter Zijlstra wrote:
+struct module;
+
+struct mod_tree_node {
+ struct latch_tree_node node;
+ struct module *mod;
+};
The module pointer should be first in this structure.
--
To unsubscribe from this list: send the line unsubscribe
On Thu, Apr 09, 2015 at 04:55:05PM +0800, Lai Jiangshan wrote:
This sentence is talking about module.c not latch_tree.h. So I guess
it is user(module.c)'s problem, not latch_tree.h's problem.
The user(module.c) can wrap the struct latch_tree_nodes and add @priv.
OK, took me a while to figure
On Thu, Apr 9, 2015 at 9:59 AM, Peter Zijlstra pet...@infradead.org wrote:
I was a little surprised myself it worked, but its a constant after
all so it 'should'.
Well, it should actually work for non-constants too, even when that
'idx' isn't inlined to one of the fixed constants. So even if
On Thu, Apr 09, 2015 at 04:09:07PM +0800, Lai Jiangshan wrote:
On 04/09/2015 12:48 AM, Peter Zijlstra wrote:
+
+struct latch_tree_node {
+ /*
+* Because we have an array of two entries in struct latch_tree_nodes
+* it's not possible to use container_of() to get back to the
On Thu, Apr 9, 2015 at 5:13 AM, Peter Zijlstra pet...@infradead.org wrote:
struct latch_tree_node {
+ struct rb_node node[2];
};
+static __always_inline struct latch_tree_node *
+__lt_from_rb(struct rb_node *node, int idx)
+{
+ return container_of(node, struct
On 04/09/2015 12:48 AM, Peter Zijlstra wrote:
+
+struct latch_tree_node {
+ /*
+ * Because we have an array of two entries in struct latch_tree_nodes
+ * it's not possible to use container_of() to get back to the
+ * encapsulating structure; therefore we have to put in a
On Thu, Apr 9, 2015 at 10:12 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
It's just unusual, which I think makes it slightly harder to read for
a *human* just because it breaks the normal pattern of those things.
But there's nothing technically wrong with it.
You could have written
Implement a latched RB-tree in order to get unconditional RCU/lockless
lookups.
Cc: Mathieu Desnoyers
Cc: "Paul E. McKenney"
Cc: Oleg Nesterov
Cc: Michel Lespinasse
Cc: Andrea Arcangeli
Cc: David Woodhouse
Cc: Rik van Riel
Signed-off-by: Peter Zijlstra (Intel)
---
Implement a latched RB-tree in order to get unconditional RCU/lockless
lookups.
Cc: Mathieu Desnoyers mathieu.desnoy...@efficios.com
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Oleg Nesterov o...@redhat.com
Cc: Michel Lespinasse wal...@google.com
Cc: Andrea Arcangeli aarca...@redhat.com
20 matches
Mail list logo
