[PATCH] kernel: x86: tboot: Replace mdelay with usleep_range in tboot_wait_for_aps

[PATCH] kernel: x86: tboot: Replace mdelay with usleep_range in tboot_wait_for_aps

[Jia-Ju Bai]

The function tboot_wait_for_aps is not called in atomic context.
Thus mdelay can be replaced with usleep_range, to reduce busy wait.

Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
 arch/x86/kernel/tboot.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
index a4eb279..c1d523e 100644
--- a/arch/x86/kernel/tboot.c
+++ b/arch/x86/kernel/tboot.c
@@ -317,7 +317,7 @@ static int tboot_wait_for_aps(int num_aps)
 	timeout = AP_WAIT_TIMEOUT*HZ;
 	while (atomic_read((atomic_t *)&tboot->num_in_wfs) != num_aps &&
 	       timeout) {
-		mdelay(1);
+		usleep_range(1000, 2000);
 		timeout--;
 	}
 
-- 
1.7.9.5

Re: [PATCH] kernel: x86: tboot: Replace mdelay with usleep_range in tboot_wait_for_aps

[Thomas Gleixner]

On Wed, 24 Jan 2018, Jia-Ju Bai wrote:

> The function tboot_wait_for_aps is not called in atomic context.
> Thus mdelay can be replaced with usleep_range, to reduce busy wait.

And how did you establish that it's not called in atomic context?

Thanks,

	tglx

Re: [PATCH] kernel: x86: tboot: Replace mdelay with usleep_range in tboot_wait_for_aps

[Jia-Ju Bai]

On 2018/1/24 19:47, Thomas Gleixner wrote:
> On Wed, 24 Jan 2018, Jia-Ju Bai wrote:
>
>> The function tboot_wait_for_aps is not called in atomic context.
>> Thus mdelay can be replaced with usleep_range, to reduce busy wait.
> And how did you establish that it's not called in atomic context?
>
> Thanks,
>
> 	tglx

It is reported by a static analysis tool written by myself.
This tool finds that mdelay in tboot_wait_for_aps is not called by 
holding a spinlock or in an interrupt handler, thus mdelay can be replaced.


Thanks,
Jia-Ju Bai

RE: [PATCH] kernel: x86: tboot: Replace mdelay with usleep_range in tboot_wait_for_aps

[Sun, Ning]

It looks like tboot_wait_for_aps(...) is not called in atomic context .

mdelay(1) delays exactly 1msecs, I understand udelay(...) may not be  appropriate, as it is used for delay around 20usecs.
In terms of reducing busy wait, how can we determine the range in usleep_range(...) is 1000 to 2000, not from 20 to 1000?

Thanks,
-ning 


-----Original Message-----
From: Jia-Ju Bai [mailto:baijiaju1990@gmail.com] 
Sent: Wednesday, January 24, 2018 5:38 AM
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Sun, Ning <ning.sun@intel.com>; mingo@redhat.com; hpa@zytor.com; x86@kernel.org; tboot-devel@lists.sourceforge.net; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kernel: x86: tboot: Replace mdelay with usleep_range in tboot_wait_for_aps


On 2018/1/24 19:47, Thomas Gleixner wrote:
> On Wed, 24 Jan 2018, Jia-Ju Bai wrote:
>
>> The function tboot_wait_for_aps is not called in atomic context.
>> Thus mdelay can be replaced with usleep_range, to reduce busy wait.
> And how did you establish that it's not called in atomic context?
>
> Thanks,
>
> 	tglx

It is reported by a static analysis tool written by myself.
This tool finds that mdelay in tboot_wait_for_aps is not called by holding a spinlock or in an interrupt handler, thus mdelay can be replaced.


Thanks,
Jia-Ju Bai

RE: [PATCH] kernel: x86: tboot: Replace mdelay with usleep_range in tboot_wait_for_aps

[Thomas Gleixner]

On Wed, 24 Jan 2018, Sun, Ning wrote:

Please do NOT top post and do NOT include the whole mail header in your
reply.

> >> The function tboot_wait_for_aps is not called in atomic context.
> >> Thus mdelay can be replaced with usleep_range, to reduce busy wait.
> > And how did you establish that it's not called in atomic context?
> >
> It is reported by a static analysis tool written by myself.  This tool
> finds that mdelay in tboot_wait_for_aps is not called by holding a
> spinlock or in an interrupt handler, thus mdelay can be replaced.

> It looks like tboot_wait_for_aps(...) is not called in atomic context .

You are both failing to look at the calling context of this. Care to follow
the invocation chain and look at the context?

Thanks,

	tglx