From: Nathan Lynch <ntl@pobox.com>
To: Jan-Bernd Themann <ossthema@de.ibm.com>
Cc: Thomas Klein <tklein@de.ibm.com>, netdev <netdev@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-ppc <linuxppc-dev@ozlabs.org>,
Christoph Raisch <raisch@de.ibm.com>,
Marcus Eder <meder@de.ibm.com>
Subject: Re: [PATCH 2/6] ehea: pHYP interface
Date: Fri, 11 Aug 2006 16:19:15 -0500 [thread overview]
Message-ID: <20060811211915.GL3233@localdomain> (raw)
In-Reply-To: <44D99F1A.4080905@de.ibm.com>
Hi-
Jan-Bernd Themann wrote:
> +static inline long ehea_hcall_9arg_9ret(unsigned long opcode,
> + unsigned long arg1,
> + unsigned long arg2,
> + unsigned long arg3,
> + unsigned long arg4,
> + unsigned long arg5,
> + unsigned long arg6,
> + unsigned long arg7,
> + unsigned long arg8,
> + unsigned long arg9,
> + unsigned long *out1,
> + unsigned long *out2,
> + unsigned long *out3,
> + unsigned long *out4,
> + unsigned long *out5,
> + unsigned long *out6,
> + unsigned long *out7,
> + unsigned long *out8,
> + unsigned long *out9)
> +{
> + long hret = H_SUCCESS;
> + int i, sleep_msecs;
> +
> + EDEB_EN(7, "opcode=%lx arg1=%lx arg2=%lx arg3=%lx arg4=%lx "
> + "arg5=%lx arg6=%lx arg7=%lx arg8=%lx arg9=%lx",
> + opcode, arg1, arg2, arg3, arg4, arg5, arg6, arg7,
> + arg8, arg9);
> +
> +
> + for (i = 0; i < 5; i++) {
> + hret = plpar_hcall_9arg_9ret(opcode,
> + arg1, arg2, arg3, arg4,
> + arg5, arg6, arg7, arg8,
> + arg9,
> + out1, out2, out3, out4,
> + out5, out6, out7, out8,
> + out9);
> +
> + if (H_IS_LONG_BUSY(hret)) {
> + sleep_msecs = get_longbusy_msecs(hret);
> + msleep_interruptible(sleep_msecs);
> + continue;
> + }
Looping five times before giving up seems arbitrary and failure-prone
on busy systems.
Is msleep_interruptible (as opposed to msleep) really appropriate?
Hope all the callers of this function are in non-atomic context (but I
wasn't able to find any callers?).
And this function is too big to be inline.
WARNING: multiple messages have this Message-ID (diff)
From: Nathan Lynch <ntl@pobox.com>
To: Jan-Bernd Themann <ossthema@de.ibm.com>
Cc: netdev <netdev@vger.kernel.org>, Thomas Klein <tklein@de.ibm.com>,
linux-ppc <linuxppc-dev@ozlabs.org>,
Christoph Raisch <raisch@de.ibm.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Marcus Eder <meder@de.ibm.com>
Subject: Re: [PATCH 2/6] ehea: pHYP interface
Date: Fri, 11 Aug 2006 16:19:15 -0500 [thread overview]
Message-ID: <20060811211915.GL3233@localdomain> (raw)
In-Reply-To: <44D99F1A.4080905@de.ibm.com>
Hi-
Jan-Bernd Themann wrote:
> +static inline long ehea_hcall_9arg_9ret(unsigned long opcode,
> + unsigned long arg1,
> + unsigned long arg2,
> + unsigned long arg3,
> + unsigned long arg4,
> + unsigned long arg5,
> + unsigned long arg6,
> + unsigned long arg7,
> + unsigned long arg8,
> + unsigned long arg9,
> + unsigned long *out1,
> + unsigned long *out2,
> + unsigned long *out3,
> + unsigned long *out4,
> + unsigned long *out5,
> + unsigned long *out6,
> + unsigned long *out7,
> + unsigned long *out8,
> + unsigned long *out9)
> +{
> + long hret = H_SUCCESS;
> + int i, sleep_msecs;
> +
> + EDEB_EN(7, "opcode=%lx arg1=%lx arg2=%lx arg3=%lx arg4=%lx "
> + "arg5=%lx arg6=%lx arg7=%lx arg8=%lx arg9=%lx",
> + opcode, arg1, arg2, arg3, arg4, arg5, arg6, arg7,
> + arg8, arg9);
> +
> +
> + for (i = 0; i < 5; i++) {
> + hret = plpar_hcall_9arg_9ret(opcode,
> + arg1, arg2, arg3, arg4,
> + arg5, arg6, arg7, arg8,
> + arg9,
> + out1, out2, out3, out4,
> + out5, out6, out7, out8,
> + out9);
> +
> + if (H_IS_LONG_BUSY(hret)) {
> + sleep_msecs = get_longbusy_msecs(hret);
> + msleep_interruptible(sleep_msecs);
> + continue;
> + }
Looping five times before giving up seems arbitrary and failure-prone
on busy systems.
Is msleep_interruptible (as opposed to msleep) really appropriate?
Hope all the callers of this function are in non-atomic context (but I
wasn't able to find any callers?).
And this function is too big to be inline.
next prev parent reply other threads:[~2006-08-11 21:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-09 8:38 [PATCH 2/6] ehea: pHYP interface Jan-Bernd Themann
2006-08-09 8:38 ` Jan-Bernd Themann
2006-08-09 13:14 ` Arnd Bergmann
2006-08-09 13:14 ` Arnd Bergmann
2006-08-09 13:14 ` Arnd Bergmann
2006-08-10 15:12 ` Thomas Klein
2006-08-10 15:12 ` Thomas Klein
2006-08-11 21:13 ` Anton Blanchard
2006-08-11 21:13 ` Anton Blanchard
2006-08-14 13:14 ` Jan-Bernd Themann
2006-08-14 13:14 ` Jan-Bernd Themann
2006-08-11 21:19 ` Nathan Lynch [this message]
2006-08-11 21:19 ` Nathan Lynch
2006-08-11 21:26 ` Nathan Lynch
2006-08-21 12:04 ` Jan-Bernd Themann
2006-08-21 12:04 ` Jan-Bernd Themann
-- strict thread matches above, loose matches on Subject: below --
2006-06-21 12:40 Jan-Bernd Themann
2006-06-21 15:36 ` Roland Dreier
2006-06-26 16:17 ` Heiko J Schick
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=20060811211915.GL3233@localdomain \
--to=ntl@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=meder@de.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=ossthema@de.ibm.com \
--cc=raisch@de.ibm.com \
--cc=tklein@de.ibm.com \
/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.