All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vijay Kumar <vijay.ac.kumar@oracle.com>
To: David Miller <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org, rob.gardner@oracle.com,
	anthony.yznaga@oracle.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] sparc64: Use low latency path to resume idle cpu
Date: Fri, 21 Jul 2017 02:44:24 +0000	[thread overview]
Message-ID: <dbe44a81-e5fd-3baf-084e-475db05ba397@oracle.com> (raw)
In-Reply-To: <20170720.125710.1645099626446989744.davem@davemloft.net>



On 7/20/2017 2:57 PM, David Miller wrote:
> From: Vijay Kumar <vijay.ac.kumar@oracle.com>
> Date: Sat,  8 Jul 2017 14:23:42 -0600
>
>> cpu_poke is a low latency path to resume the target cpu if suspended
>> using cpu_yield. Use cpu poke to resume cpu if supported by hypervisor.
>>
>> 	     hackbench results (lower is better):
>> Number of		
>> Process:		w/o fix		with fix
>> 1  			0.012		 0.010
>> 10			0.021		 0.019
>> 100			0.151		 0.148
> So this only works for a cpu which has yielded.
>
> The kernel sends reschedule events to both idle and non-idle cpus.
> That's why you have to have that fallback code to still send the
> mondo IPI right?
That is correct.

>
> For the case where POKE works, it seems like completely unnecessary
> overhead to set the PIL interrupt.  Just disable local cpu interrupts
> and call schedule_ipi() directly.
>
> I bet that improves your benchmark even more.

I had same thoughts initially but I had to go with this approach as 
scheduler_ipi is wrapped with irq_enter() and irq_exit(). Whereas POKE 
resumes the cpu in process context.

Comments in scheduler_ipi():

          * Not all reschedule IPI handlers call irq_enter/irq_exit, since
          * traditionally all their work was done from the interrupt return
          * path. Now that we actually do some work, we need to make sure
          * we do call them.
          *
          * Some archs already do call them, luckily irq_enter/exit nest
          * properly.
          *
          * Arguably we should visit all archs and update all handlers,
          * however a fair share of IPIs are still resched only so this 
would
          * somewhat pessimize the simple resched case.
          */
         irq_enter();


-Vijay


WARNING: multiple messages have this Message-ID (diff)
From: Vijay Kumar <vijay.ac.kumar@oracle.com>
To: David Miller <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org, rob.gardner@oracle.com,
	anthony.yznaga@oracle.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] sparc64: Use low latency path to resume idle cpu
Date: Thu, 20 Jul 2017 21:44:24 -0500	[thread overview]
Message-ID: <dbe44a81-e5fd-3baf-084e-475db05ba397@oracle.com> (raw)
In-Reply-To: <20170720.125710.1645099626446989744.davem@davemloft.net>



On 7/20/2017 2:57 PM, David Miller wrote:
> From: Vijay Kumar <vijay.ac.kumar@oracle.com>
> Date: Sat,  8 Jul 2017 14:23:42 -0600
>
>> cpu_poke is a low latency path to resume the target cpu if suspended
>> using cpu_yield. Use cpu poke to resume cpu if supported by hypervisor.
>>
>> 	     hackbench results (lower is better):
>> Number of		
>> Process:		w/o fix		with fix
>> 1  			0.012		 0.010
>> 10			0.021		 0.019
>> 100			0.151		 0.148
> So this only works for a cpu which has yielded.
>
> The kernel sends reschedule events to both idle and non-idle cpus.
> That's why you have to have that fallback code to still send the
> mondo IPI right?
That is correct.

>
> For the case where POKE works, it seems like completely unnecessary
> overhead to set the PIL interrupt.  Just disable local cpu interrupts
> and call schedule_ipi() directly.
>
> I bet that improves your benchmark even more.

I had same thoughts initially but I had to go with this approach as 
scheduler_ipi is wrapped with irq_enter() and irq_exit(). Whereas POKE 
resumes the cpu in process context.

Comments in scheduler_ipi():

          * Not all reschedule IPI handlers call irq_enter/irq_exit, since
          * traditionally all their work was done from the interrupt return
          * path. Now that we actually do some work, we need to make sure
          * we do call them.
          *
          * Some archs already do call them, luckily irq_enter/exit nest
          * properly.
          *
          * Arguably we should visit all archs and update all handlers,
          * however a fair share of IPIs are still resched only so this 
would
          * somewhat pessimize the simple resched case.
          */
         irq_enter();


-Vijay

  reply	other threads:[~2017-07-21  2:44 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-08 20:23 [PATCH 0/2] sparc64: Use low latency path to resume idle cpu Vijay Kumar
2017-07-08 20:23 ` Vijay Kumar
2017-07-08 20:23 ` [PATCH 1/2] sparc64: Add a new hypercall CPU_POKE Vijay Kumar
2017-07-08 20:23   ` Vijay Kumar
2017-07-08 20:23 ` [PATCH 2/2] sparc64: Use cpu_poke to resume idle cpu Vijay Kumar
2017-07-08 20:23   ` Vijay Kumar
2017-07-20 19:58   ` David Miller
2017-07-20 19:58     ` David Miller
2017-07-21  2:47     ` Vijay Kumar
2017-07-21  2:47       ` Vijay Kumar
2017-07-20 19:57 ` [PATCH 0/2] sparc64: Use low latency path " David Miller
2017-07-20 19:57   ` David Miller
2017-07-21  2:44   ` Vijay Kumar [this message]
2017-07-21  2:44     ` Vijay Kumar
2017-07-21  2:55     ` David Miller
2017-07-21  2:55       ` David Miller
2017-07-21  3:36       ` Vijay Kumar
2017-07-21  3:36         ` Vijay Kumar
2017-07-21  3:45         ` David Miller
2017-07-21  3:45           ` David Miller
2017-07-21  4:11           ` Vijay Kumar
2017-07-21  4:11             ` Vijay Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dbe44a81-e5fd-3baf-084e-475db05ba397@oracle.com \
    --to=vijay.ac.kumar@oracle.com \
    --cc=anthony.yznaga@oracle.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rob.gardner@oracle.com \
    --cc=sparclinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.