[PATCH] IB/ehca: use kthread_create_on_node

[PATCH] IB/ehca: use kthread_create_on_node

[Eric Dumazet]

Since create_comp_task() creates percpu kthread, it makes
sense to use kthread_create_on_node() to get proper NUMA affinity for
kthread stack.

Signed-off-by: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
CC: Hoang-Nam Nguyen <hnguyen-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
CC: Christoph Raisch <raisch-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
CC: Roland Dreier <roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
CC: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 drivers/infiniband/hw/ehca/ehca_irq.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/ehca/ehca_irq.c b/drivers/infiniband/hw/ehca/ehca_irq.c
index e571e60..5358900 100644
--- a/drivers/infiniband/hw/ehca/ehca_irq.c
+++ b/drivers/infiniband/hw/ehca/ehca_irq.c
@@ -786,7 +786,8 @@ static struct task_struct *create_comp_task(struct ehca_comp_pool *pool,
 	spin_lock_init(&cct->task_lock);
 	INIT_LIST_HEAD(&cct->cq_list);
 	init_waitqueue_head(&cct->wait_queue);
-	cct->task = kthread_create(comp_task, cct, "ehca_comp/%d", cpu);
+	cct->task = kthread_create_on_node(comp_task, cct, cpu_to_node(cpu),
+					   "ehca_comp/%d", cpu);
 
 	return cct->task;
 }


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] IB/ehca: use kthread_create_on_node

[Eric Dumazet]

Since create_comp_task() creates percpu kthread, it makes
sense to use kthread_create_on_node() to get proper NUMA affinity for
kthread stack.

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Hoang-Nam Nguyen <hnguyen@de.ibm.com>
CC: Christoph Raisch <raisch@de.ibm.com>
CC: Roland Dreier <roland@kernel.org>
CC: Sean Hefty <sean.hefty@intel.com>
---
 drivers/infiniband/hw/ehca/ehca_irq.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/ehca/ehca_irq.c b/drivers/infiniband/hw/ehca/ehca_irq.c
index e571e60..5358900 100644
--- a/drivers/infiniband/hw/ehca/ehca_irq.c
+++ b/drivers/infiniband/hw/ehca/ehca_irq.c
@@ -786,7 +786,8 @@ static struct task_struct *create_comp_task(struct ehca_comp_pool *pool,
 	spin_lock_init(&cct->task_lock);
 	INIT_LIST_HEAD(&cct->cq_list);
 	init_waitqueue_head(&cct->wait_queue);
-	cct->task = kthread_create(comp_task, cct, "ehca_comp/%d", cpu);
+	cct->task = kthread_create_on_node(comp_task, cct, cpu_to_node(cpu),
+					   "ehca_comp/%d", cpu);
 
 	return cct->task;
 }

Re: [PATCH] IB/ehca: use kthread_create_on_node

[Roland Dreier]

On Fri, Jul 29, 2011 at 12:15 AM, Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Since create_comp_task() creates percpu kthread, it makes
> sense to use kthread_create_on_node() to get proper NUMA affinity for
> kthread stack.

Seems eminently sane to me.  ehca guys, any concern about this?

 - R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] IB/ehca: use kthread_create_on_node

[Roland Dreier]

On Fri, Jul 29, 2011 at 12:15 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Since create_comp_task() creates percpu kthread, it makes
> sense to use kthread_create_on_node() to get proper NUMA affinity for
> kthread stack.

Seems eminently sane to me.  ehca guys, any concern about this?

 - R.

Re: [PATCH] IB/ehca: use kthread_create_on_node

[Hoang-Nam Nguyen]

Hi Roland,
This patch looks fine to me.
Thanks
Nam

roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org wrote on 29.07.2011 19:10:32:

> [image removed]
>
> Re: [PATCH] IB/ehca: use kthread_create_on_node
>
> Roland Dreier
>
> to:
>
> Eric Dumazet
>
> 29.07.2011 19:11
>
> Sent by:
>
> roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org
>
> Cc:
>
> Hoang-Nam Nguyen, Christoph Raisch, Sean Hefty, linux-rdma, linux-kernel
>
> On Fri, Jul 29, 2011 at 12:15 AM, Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> > Since create_comp_task() creates percpu kthread, it makes
> > sense to use kthread_create_on_node() to get proper NUMA affinity for
> > kthread stack.
>
> Seems eminently sane to me.  ehca guys, any concern about this?
>
>  - R.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] IB/ehca: use kthread_create_on_node

[Hoang-Nam Nguyen]

Hi Roland,
This patch looks fine to me.
Thanks
Nam

roland@purestorage.com wrote on 29.07.2011 19:10:32:

> [image removed]
>
> Re: [PATCH] IB/ehca: use kthread_create_on_node
>
> Roland Dreier
>
> to:
>
> Eric Dumazet
>
> 29.07.2011 19:11
>
> Sent by:
>
> roland@purestorage.com
>
> Cc:
>
> Hoang-Nam Nguyen, Christoph Raisch, Sean Hefty, linux-rdma, linux-kernel
>
> On Fri, Jul 29, 2011 at 12:15 AM, Eric Dumazet <eric.dumazet@gmail.com>
wrote:
> > Since create_comp_task() creates percpu kthread, it makes
> > sense to use kthread_create_on_node() to get proper NUMA affinity for
> > kthread stack.
>
> Seems eminently sane to me.  ehca guys, any concern about this?
>
>  - R.

Re: [PATCH] IB/ehca: use kthread_create_on_node

[Eric Dumazet]

Le vendredi 29 juillet 2011 à 09:15 +0200, Eric Dumazet a écrit :
> Since create_comp_task() creates percpu kthread, it makes
> sense to use kthread_create_on_node() to get proper NUMA affinity for
> kthread stack.
> 
> Signed-off-by: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: Hoang-Nam Nguyen <hnguyen-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
> CC: Christoph Raisch <raisch-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
> CC: Roland Dreier <roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> CC: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> ---
>  drivers/infiniband/hw/ehca/ehca_irq.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/infiniband/hw/ehca/ehca_irq.c b/drivers/infiniband/hw/ehca/ehca_irq.c
> index e571e60..5358900 100644
> --- a/drivers/infiniband/hw/ehca/ehca_irq.c
> +++ b/drivers/infiniband/hw/ehca/ehca_irq.c
> @@ -786,7 +786,8 @@ static struct task_struct *create_comp_task(struct ehca_comp_pool *pool,
>  	spin_lock_init(&cct->task_lock);
>  	INIT_LIST_HEAD(&cct->cq_list);
>  	init_waitqueue_head(&cct->wait_queue);
> -	cct->task = kthread_create(comp_task, cct, "ehca_comp/%d", cpu);
> +	cct->task = kthread_create_on_node(comp_task, cct, cpu_to_node(cpu),
> +					   "ehca_comp/%d", cpu);
>  
>  	return cct->task;
>  }
> 


Any news on this patch ?

Should I submit it again ?



--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] IB/ehca: use kthread_create_on_node

[Eric Dumazet]

Le vendredi 29 juillet 2011 à 09:15 +0200, Eric Dumazet a écrit :
> Since create_comp_task() creates percpu kthread, it makes
> sense to use kthread_create_on_node() to get proper NUMA affinity for
> kthread stack.
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Hoang-Nam Nguyen <hnguyen@de.ibm.com>
> CC: Christoph Raisch <raisch@de.ibm.com>
> CC: Roland Dreier <roland@kernel.org>
> CC: Sean Hefty <sean.hefty@intel.com>
> ---
>  drivers/infiniband/hw/ehca/ehca_irq.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/infiniband/hw/ehca/ehca_irq.c b/drivers/infiniband/hw/ehca/ehca_irq.c
> index e571e60..5358900 100644
> --- a/drivers/infiniband/hw/ehca/ehca_irq.c
> +++ b/drivers/infiniband/hw/ehca/ehca_irq.c
> @@ -786,7 +786,8 @@ static struct task_struct *create_comp_task(struct ehca_comp_pool *pool,
>  	spin_lock_init(&cct->task_lock);
>  	INIT_LIST_HEAD(&cct->cq_list);
>  	init_waitqueue_head(&cct->wait_queue);
> -	cct->task = kthread_create(comp_task, cct, "ehca_comp/%d", cpu);
> +	cct->task = kthread_create_on_node(comp_task, cct, cpu_to_node(cpu),
> +					   "ehca_comp/%d", cpu);
>  
>  	return cct->task;
>  }
> 


Any news on this patch ?

Should I submit it again ?

Re: [PATCH] IB/ehca: use kthread_create_on_node

[Roland Dreier]

On Thu, Feb 2, 2012 at 3:12 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Any news on this patch ?

Sorry, just dropped it in the shuffle.  I'll get it into 3.4, thanks.

Re: [PATCH] IB/ehca: use kthread_create_on_node

[Or Gerlitz]

On Thu, Feb 2, 2012 at 7:08 PM, Roland Dreier <roland@kernel.org> wrote:
> On Thu, Feb 2, 2012 at 3:12 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:

>> Any news on this patch ?

> Sorry, just dropped it in the shuffle.  I'll get it into 3.4, thanks.

Roland,

I noted that you typically use the for-next branch of the infiniband
tree for fixes during
the 1 < kernN-rc < (say) 6 time and for features during (kernN-rc > 6)
till kern(N+1)-rc1

This means that the window of time when features are actually accepted
into your tree is kind of very limited. Would it be possible to
maintain two branches: for-next and (say) rc-fixes, such that
practically patches are reviewed/accepted to for-next at almost all
times?

BTW I see that networking and scsi maintainers use two trees
(net/net-next) and (scsi-misc/scsi-rc-fixes), maybe it would be eaiser
for you go this way?

Or.

Re: [PATCH] IB/ehca: use kthread_create_on_node

[Roland Dreier]

On Wed, Feb 8, 2012 at 1:26 PM, Or Gerlitz <or.gerlitz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I noted that you typically use the for-next branch of the infiniband
> tree for fixes during
> the 1 < kernN-rc < (say) 6 time and for features during (kernN-rc > 6)
> till kern(N+1)-rc1
>
> This means that the window of time when features are actually accepted
> into your tree is kind of very limited. Would it be possible to
> maintain two branches: for-next and (say) rc-fixes, such that
> practically patches are reviewed/accepted to for-next at almost all
> times?
>
> BTW I see that networking and scsi maintainers use two trees
> (net/net-next) and (scsi-misc/scsi-rc-fixes), maybe it would be eaiser
> for you go this way?

It's not really an issue of not having a tree to put things into.  It's
more that the window when I actually review major things is not
as big as perhaps it should be.

So I generally try to get fixes in expeditiously because they're
easy to deal with, whereas I only dedicate time to merging bigger
things when I feel the pressure of the impending merge window.

I do usually have some small patches that are fine for the next window
but which I have only marked "to apply" in my mailbox, which it
might be a good idea to apply sooner so they get more -next tree
coverage.

 - R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] IB/ehca: use kthread_create_on_node

[Roland Dreier]

On Wed, Feb 8, 2012 at 1:26 PM, Or Gerlitz <or.gerlitz@gmail.com> wrote:
> I noted that you typically use the for-next branch of the infiniband
> tree for fixes during
> the 1 < kernN-rc < (say) 6 time and for features during (kernN-rc > 6)
> till kern(N+1)-rc1
>
> This means that the window of time when features are actually accepted
> into your tree is kind of very limited. Would it be possible to
> maintain two branches: for-next and (say) rc-fixes, such that
> practically patches are reviewed/accepted to for-next at almost all
> times?
>
> BTW I see that networking and scsi maintainers use two trees
> (net/net-next) and (scsi-misc/scsi-rc-fixes), maybe it would be eaiser
> for you go this way?

It's not really an issue of not having a tree to put things into.  It's
more that the window when I actually review major things is not
as big as perhaps it should be.

So I generally try to get fixes in expeditiously because they're
easy to deal with, whereas I only dedicate time to merging bigger
things when I feel the pressure of the impending merge window.

I do usually have some small patches that are fine for the next window
but which I have only marked "to apply" in my mailbox, which it
might be a good idea to apply sooner so they get more -next tree
coverage.

 - R.

Re: [PATCH] IB/ehca: use kthread_create_on_node

[Or Gerlitz]

On Wed, Feb 8, 2012 at 11:35 PM, Roland Dreier <roland@kernel.org> wrote:
> On Wed, Feb 8, 2012 at 1:26 PM, Or Gerlitz <or.gerlitz@gmail.com> wrote:

>> [...] This means that the window of time when features are actually accepted
>> into your tree is kind of very limited. Would it be possible to
>> maintain two branches: for-next and (say) rc-fixes, such that
>> practically patches are reviewed/accepted to for-next at almost all times?

>> BTW I see that networking and scsi maintainers use two trees (net/net-next)
>> and (scsi-misc/scsi-rc-fixes), maybe it would be eaiser for you go this way?

> It's not really an issue of not having a tree to put things into.  It's
> more that the window when I actually review major things is not
> as big as perhaps it should be.

> So I generally try to get fixes in expeditiously because they're
> easy to deal with, whereas I only dedicate time to merging bigger
> things when I feel the pressure of the impending merge window.

but bigger things need bigger time to deal with... but even before we
address that -

> I do usually have some small patches that are fine for the next window
> but which I have only marked "to apply" in my mailbox, which it
> might be a good idea to apply sooner so they get more -next tree coverage.

Yep, having a branch where patches you accept are applied sooner
rather then later,
will be a little but surely nice && important step in the right
direction... it would be great to have this, could you make that
happen?

Also, to except for patches which you reviewed and willing to accept,
it happens that Sean Hefty who is also a maintainer, reviews patches
and provides his reviewed-by signature. I would say such patches could
(should) go to that branch as well and not wait to the pressure of the
impending merge window.

How does all this sound?

Or.