From: Matt Domsch <Matt_Domsch@dell.com>
To: Nish Aravamudan <nish.aravamudan@gmail.com>
Cc: Andrew Morton <akpm@osdl.org>,
minyard@acm.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 9/9] ipmi: add timer thread
Date: Sun, 23 Oct 2005 16:27:18 -0500 [thread overview]
Message-ID: <20051023212718.GA23212@lists.us.dell.com> (raw)
In-Reply-To: <29495f1d0510231412n41ab2d27y41f13a9c9e62b0c2@mail.gmail.com>
On Sun, Oct 23, 2005 at 02:12:51PM -0700, Nish Aravamudan wrote:
> On 10/23/05, Andrew Morton <akpm@osdl.org> wrote:
> > The first call to schedule_timeout() here will not actually sleep at all,
> > due to it being in state TASK_RUNNING. Is that deliberate?
Wasn't intentional, but doesn't really matter.
> > Also, this thread can exit in state TASK_INTERUPTIBLE. That's not a bug
> > per-se, but apparently it'll spit a warning in some of the patches which
> > Ingo is working on. I don't know why, but I'm sure there's a good reason
> > ;)
>
> You beat me to this one, Andrew! :) Both issue can be avoided by using
> schedule_timeout_interruptible().
OK.
> Additionally, I think the last variable is simply being used to switch
> between a 0 and 1 jiffy sleep (took me a while to figure that out in
> GMail sadly -- any chance the variable could be renamed?). In the
> current implementaion of schedule_timeout(), these will result in the
> same behavior, expiring the timer at the next timer interrupt (the
> next jiffy increment is the first time we'll notice we had a timer in
> the past to expire). Not sure if that's the intent and perhaps just a
> means to indicate what is desired (a sleep will still occur, even
> though a udelay() has already in the loop, for instance), but wanted
> to make sure.
I think I need to move the schedule_timeout_interruptable() into the
else clause, not at the top of the loop, as that's really the only
case where I want it to sleep. In a former version of the patch, the
SI_SM_CALL_WITH_DELAY was supposed to be a 1-jiffy delay, while the
else clause was a several-jiffy delay. However, that lead to most
commands still taking too long to complete, hence the CALL_WITH_DELAY
case became a udelay(1).
I'll code up and test a patch that does this, and will send that ASAP.
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
next prev parent reply other threads:[~2005-10-23 21:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-21 14:58 [PATCH 9/9] ipmi: add timer thread Corey Minyard
2005-10-23 20:49 ` Andrew Morton
2005-10-23 21:12 ` Nish Aravamudan
2005-10-23 21:27 ` Matt Domsch [this message]
2005-10-24 20:11 ` George Anzinger
2005-10-24 20:31 ` [PATCH 2.6.14-rc5-mm1] ipmi: use kthread API Matt Domsch
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=20051023212718.GA23212@lists.us.dell.com \
--to=matt_domsch@dell.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=minyard@acm.org \
--cc=nish.aravamudan@gmail.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.