[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <MDEHLPKNGKAHNMBLJOLKKEBPFGAC.davids@webmaster.com>
Date: Tue, 17 Jul 2007 14:16:39 -0700
From: "David Schwartz" <davids@...master.com>
To: "Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
"Ian Kent" <raven@...maw.net>
Cc: "Chuck Ebbert" <cebbert@...hat.com>,
"Bill Davidsen" <davidsen@....com>
Subject: RE: [patch] CFS scheduler, -v19
> * Ian Kent <raven@...maw.net> wrote:
>
> > Yes it does and I have two reported bugs so far.
> >
> > In several places I have code similar to:
> >
> > wait.tv_sec = time(NULL) + 1;
> > wait.tv_nsec = 0;
> >
> > signaled = 0;
> > while (!signaled) {
> > status = pthread_cond_timedwait(&cond, &mutex, &wait);
> > if (status) {
> > if (status == ETIMEDOUT)
> > break;
> > fatal(status);
> > }
> > }
>
> ah! It passes in a low-res time source into a high-res time interface
> (pthread_cond_timedwait()). Could you change the time(NULL) + 1 to
> time(NULL) + 2, or change it to:
>
> gettimeofday(&wait, NULL);
> wait.tv_sec++;
>
> does this solve the spinning?
>
> i'm wondering how widespread this is. If automount is the only app doing
> this then _maybe_ we could get away with it by changing automount?
This code is horribly broken. Don't change the kernel because this code is
broken.
First it adds a second, but then it subtracts up to a second. Just before
the second boundary, this code can burn CPU like crazy, with each wait being
just a few nanoseconds.
What is the intent of this code? Is it to wait "up to a second, possibly for
no time at all" or is to wait "for at least a second"? If so, why are you
zeroing the nanosecond count?
DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists