Hi,
On Mon, 16 Jul 2007, Jonathan Corbet wrote:
> > That's a bit my problem - we have to consider other setups as well.
> > Is it worth converting all msleep users behind their back or should we
> > just a provide a separate function for those who care?
>
> Any additional overhead is clearly
Hi,
On Mon, 16 Jul 2007, Jonathan Corbet wrote:
That's a bit my problem - we have to consider other setups as well.
Is it worth converting all msleep users behind their back or should we
just a provide a separate function for those who care?
Any additional overhead is clearly small -
On 7/16/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Nish Aravamudan wrote:
> Well, before these changes, the only guarantee msleep() could make,
> just like the only guarantee schedule_timeout() could make, was that
> it would not return early. The 1-jiffy sleep was always tough to deal
> with,
Nish Aravamudan wrote:
Well, before these changes, the only guarantee msleep() could make,
just like the only guarantee schedule_timeout() could make, was that
it would not return early. The 1-jiffy sleep was always tough to deal
with, because of rounding and such. And it's simply exacerbated
Nish Aravamudan wrote:
Well, before these changes, the only guarantee msleep() could make,
just like the only guarantee schedule_timeout() could make, was that
it would not return early. The 1-jiffy sleep was always tough to deal
with, because of rounding and such. And it's simply exacerbated
On 7/16/07, Nick Piggin [EMAIL PROTECTED] wrote:
Nish Aravamudan wrote:
Well, before these changes, the only guarantee msleep() could make,
just like the only guarantee schedule_timeout() could make, was that
it would not return early. The 1-jiffy sleep was always tough to deal
with,
Roman Zippel <[EMAIL PROTECTED]> wrote:
> > That's a possibility, I admit I haven't benchmarked it. I will say that
> > I don't think it will be enough to matter - msleep() is not a hot-path
> > sort of function. Once the system is up and running it almost never
> > gets called at all - at
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
> I explained it numerous times (remember the 'timeout' vs. 'timer event'
> discussion?) that i consider timer granularity important to scalability.
> Basically, in every case where we know with great certainty that a
> time-out will _not_ occur
* Roman Zippel <[EMAIL PROTECTED]> wrote:
> I know that Ingo considers everything HZ related evil, [...]
no, you are misrepresenting me, i dont consider everything HZ related
evil - where did you get that from?
I explained it numerous times (remember the 'timeout' vs. 'timer event'
On 7/16/07, Ray Lee <[EMAIL PROTECTED]> wrote:
On 7/16/07, Roman Zippel <[EMAIL PROTECTED]> wrote:
> On Mon, 16 Jul 2007, Jonathan Corbet wrote:
> > > One possible problem here is that setting up that timer can be
> > > considerably more expensive, for a relative timer you have to read the
> > >
On 7/16/07, Roman Zippel <[EMAIL PROTECTED]> wrote:
On Mon, 16 Jul 2007, Jonathan Corbet wrote:
> > One possible problem here is that setting up that timer can be
> > considerably more expensive, for a relative timer you have to read the
> > current time, which can be quite expensive (e.g. your
Hi,
On Mon, 16 Jul 2007, Jonathan Corbet wrote:
> > One possible problem here is that setting up that timer can be
> > considerably more expensive, for a relative timer you have to read the
> > current time, which can be quite expensive (e.g. your machine now uses the
> > PIT timer, because
* Jonathan Corbet <[EMAIL PROTECTED]> wrote:
> In the end, I did this because I thought msleep() should do what it
> claims to do, because I thought that getting a known-to-expire timeout
> off the timer wheel made sense, and to make a tiny baby step in the
> direction of reducing the use of
Hey, Roman,
> One possible problem here is that setting up that timer can be
> considerably more expensive, for a relative timer you have to read the
> current time, which can be quite expensive (e.g. your machine now uses the
> PIT timer, because TSC was deemed unstable).
That's a
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
> because when i assumed the obvious, you called it an
> insult so please dont leave any room for assumptions and remove any
> ambiguity - especially as our communication seems to be marred by what
> appears to be frequent misunderstandings ;-)
Hi,
On Sun, 15 Jul 2007, Jonathan Corbet wrote:
> The OLPC folks and I recently discovered something interesting: on a
> HZ=100 system, a call to msleep(1) will delay for about 20ms. The
> combination of jiffies timekeeping and rounding up means that the
> minimum delay from msleep will be two
* Roman Zippel <[EMAIL PROTECTED]> wrote:
> One question here would be, is it really a problem to sleep a little
> more? Another possibility would be to add another sleep function,
> which uses hrtimer and could also take ktime argument.
i'm not sure how this helps your argument, could you
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
> > Well, you cut out the major question from my initial mail:
> > One question here would be, is it really a problem to sleep a little more?
>
> oh, i did not want to embarrass you (and distract the discussion) with
> answering a pretty stupid,
* Roman Zippel <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Mon, 16 Jul 2007, Ingo Molnar wrote:
>
> > i'm not sure how your question relates/connects to what i wrote above,
> > could you please re-phrase your question into a bit more verbose form so
> > that i can answer it? Thanks,
>
> Well,
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
> i'm not sure how your question relates/connects to what i wrote above,
> could you please re-phrase your question into a bit more verbose form so
> that i can answer it? Thanks,
Well, you cut out the major question from my initial mail:
One
* Roman Zippel <[EMAIL PROTECTED]> wrote:
> > > One possible problem here is that setting up that timer can be
> > > considerably more expensive, for a relative timer you have to read
> > > the current time, which can be quite expensive (e.g. your machine
> > > now uses the PIT timer,
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
> i dont think there's any significant overhead. The OLPC folks are pretty
> sensitive to performance,
How is a sleep function relevant to performace?
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
* Roman Zippel <[EMAIL PROTECTED]> wrote:
> > Here's another approach: a reimplementation of msleep() and
> > msleep_interruptible() using hrtimers. On a system without real
> > hrtimers this code will at least drop down to single-jiffy delays
> > much of the time (though not
Hi,
On Sun, 15 Jul 2007, Jonathan Corbet wrote:
> Here's another approach: a reimplementation of msleep() and
> msleep_interruptible() using hrtimers. On a system without real
> hrtimers this code will at least drop down to single-jiffy delays much
> of the time (though not deterministically
* Jonathan Corbet <[EMAIL PROTECTED]> wrote:
> The OLPC folks and I recently discovered something interesting: on a
> HZ=100 system, a call to msleep(1) will delay for about 20ms. The
> combination of jiffies timekeeping and rounding up means that the
> minimum delay from msleep will be two
* Jonathan Corbet [EMAIL PROTECTED] wrote:
The OLPC folks and I recently discovered something interesting: on a
HZ=100 system, a call to msleep(1) will delay for about 20ms. The
combination of jiffies timekeeping and rounding up means that the
minimum delay from msleep will be two
Hi,
On Sun, 15 Jul 2007, Jonathan Corbet wrote:
Here's another approach: a reimplementation of msleep() and
msleep_interruptible() using hrtimers. On a system without real
hrtimers this code will at least drop down to single-jiffy delays much
of the time (though not deterministically so).
* Roman Zippel [EMAIL PROTECTED] wrote:
Here's another approach: a reimplementation of msleep() and
msleep_interruptible() using hrtimers. On a system without real
hrtimers this code will at least drop down to single-jiffy delays
much of the time (though not deterministically so).
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
i dont think there's any significant overhead. The OLPC folks are pretty
sensitive to performance,
How is a sleep function relevant to performace?
bye, Roman
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
* Roman Zippel [EMAIL PROTECTED] wrote:
One possible problem here is that setting up that timer can be
considerably more expensive, for a relative timer you have to read
the current time, which can be quite expensive (e.g. your machine
now uses the PIT timer, because TSC was
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
i'm not sure how your question relates/connects to what i wrote above,
could you please re-phrase your question into a bit more verbose form so
that i can answer it? Thanks,
Well, you cut out the major question from my initial mail:
One question
* Roman Zippel [EMAIL PROTECTED] wrote:
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
i'm not sure how your question relates/connects to what i wrote above,
could you please re-phrase your question into a bit more verbose form so
that i can answer it? Thanks,
Well, you cut out the
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
Well, you cut out the major question from my initial mail:
One question here would be, is it really a problem to sleep a little more?
oh, i did not want to embarrass you (and distract the discussion) with
answering a pretty stupid, irrelevant
* Roman Zippel [EMAIL PROTECTED] wrote:
One question here would be, is it really a problem to sleep a little
more? Another possibility would be to add another sleep function,
which uses hrtimer and could also take ktime argument.
i'm not sure how this helps your argument, could you please
Hi,
On Sun, 15 Jul 2007, Jonathan Corbet wrote:
The OLPC folks and I recently discovered something interesting: on a
HZ=100 system, a call to msleep(1) will delay for about 20ms. The
combination of jiffies timekeeping and rounding up means that the
minimum delay from msleep will be two
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
because when i assumed the obvious, you called it an
insult so please dont leave any room for assumptions and remove any
ambiguity - especially as our communication seems to be marred by what
appears to be frequent misunderstandings ;-)
What
Hey, Roman,
One possible problem here is that setting up that timer can be
considerably more expensive, for a relative timer you have to read the
current time, which can be quite expensive (e.g. your machine now uses the
PIT timer, because TSC was deemed unstable).
That's a possibility, I
* Jonathan Corbet [EMAIL PROTECTED] wrote:
In the end, I did this because I thought msleep() should do what it
claims to do, because I thought that getting a known-to-expire timeout
off the timer wheel made sense, and to make a tiny baby step in the
direction of reducing the use of
Hi,
On Mon, 16 Jul 2007, Jonathan Corbet wrote:
One possible problem here is that setting up that timer can be
considerably more expensive, for a relative timer you have to read the
current time, which can be quite expensive (e.g. your machine now uses the
PIT timer, because TSC was
On 7/16/07, Roman Zippel [EMAIL PROTECTED] wrote:
On Mon, 16 Jul 2007, Jonathan Corbet wrote:
One possible problem here is that setting up that timer can be
considerably more expensive, for a relative timer you have to read the
current time, which can be quite expensive (e.g. your machine
On 7/16/07, Ray Lee [EMAIL PROTECTED] wrote:
On 7/16/07, Roman Zippel [EMAIL PROTECTED] wrote:
On Mon, 16 Jul 2007, Jonathan Corbet wrote:
One possible problem here is that setting up that timer can be
considerably more expensive, for a relative timer you have to read the
current time,
* Roman Zippel [EMAIL PROTECTED] wrote:
I know that Ingo considers everything HZ related evil, [...]
no, you are misrepresenting me, i dont consider everything HZ related
evil - where did you get that from?
I explained it numerous times (remember the 'timeout' vs. 'timer event'
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
I explained it numerous times (remember the 'timeout' vs. 'timer event'
discussion?) that i consider timer granularity important to scalability.
Basically, in every case where we know with great certainty that a
time-out will _not_ occur (where
Roman Zippel [EMAIL PROTECTED] wrote:
That's a possibility, I admit I haven't benchmarked it. I will say that
I don't think it will be enough to matter - msleep() is not a hot-path
sort of function. Once the system is up and running it almost never
gets called at all - at least, on my
On Monday 16 July 2007, Jonathan Corbet wrote:
> Here's another approach: a reimplementation of msleep() and
> msleep_interruptible() using hrtimers. On a system without real
> hrtimers this code will at least drop down to single-jiffy delays much
> of the time (though not deterministically so).
The OLPC folks and I recently discovered something interesting: on a
HZ=100 system, a call to msleep(1) will delay for about 20ms. The
combination of jiffies timekeeping and rounding up means that the
minimum delay from msleep will be two jiffies, never less. That led to
multi-second delays in a
The OLPC folks and I recently discovered something interesting: on a
HZ=100 system, a call to msleep(1) will delay for about 20ms. The
combination of jiffies timekeeping and rounding up means that the
minimum delay from msleep will be two jiffies, never less. That led to
multi-second delays in a
On Monday 16 July 2007, Jonathan Corbet wrote:
Here's another approach: a reimplementation of msleep() and
msleep_interruptible() using hrtimers. On a system without real
hrtimers this code will at least drop down to single-jiffy delays much
of the time (though not deterministically so). On
48 matches
Mail list logo
