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 sm
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, b
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 wi
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
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 (whe
* 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'
discussio
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 m
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 TS
* 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 j
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
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
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 j
* 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 ple
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, irrel
* 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, yo
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 questio
* 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
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
* 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 deterministicall
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)
* 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 j
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).
23 matches
Mail list logo
