On Friday 02 March 2007 00:30, Ingo Molnar wrote:
> * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > [...] Even though I'm finding myself defending code that has already
> > been softly tagged for redundancy, let's be clear here; we're talking
> > about at most a further 70ms delay in scheduling a
* Con Kolivas <[EMAIL PROTECTED]> wrote:
> [...] Even though I'm finding myself defending code that has already
> been softly tagged for redundancy, let's be clear here; we're talking
> about at most a further 70ms delay in scheduling a niced task in the
> presence of a nice 0 task, which is
On Thu, 2007-03-01 at 23:05 +1100, Con Kolivas wrote:
> > > And that's the depressing part because of course I was interested in that
> > > as the original approach to the problem (and it was a big problem). When
> > > I spoke to Intel and AMD (of course to date no SMT AMD chip exists) at
> > >
On Thursday 01 March 2007 22:33, Thomas Gleixner wrote:
> On Thu, 2007-03-01 at 22:13 +1100, Con Kolivas wrote:
> > > if then there should be a mechanism /in the hardware/ to set the
> > > priority of a CPU - and then the hardware could decide how to
> > > prioritize between siblings. Doing this
On Thu, 2007-03-01 at 22:13 +1100, Con Kolivas wrote:
> > if then there should be a mechanism /in the hardware/ to set the
> > priority of a CPU - and then the hardware could decide how to prioritize
> > between siblings. Doing this in software is really hard.
>
> And that's the depressing part
On Thursday 01 March 2007 19:46, Ingo Molnar wrote:
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > I see no real difference between the two assertions. Nice is just a
> > mechanism to set priority, so I applied your assertion to a different
> > range of priorities than nice covers, and
* Mike Galbraith <[EMAIL PROTECTED]> wrote:
> I see no real difference between the two assertions. Nice is just a
> mechanism to set priority, so I applied your assertion to a different
> range of priorities than nice covers, and returned it to show that the
> code contradicts itself. It
* Mike Galbraith [EMAIL PROTECTED] wrote:
I see no real difference between the two assertions. Nice is just a
mechanism to set priority, so I applied your assertion to a different
range of priorities than nice covers, and returned it to show that the
code contradicts itself. It can't be
On Thursday 01 March 2007 19:46, Ingo Molnar wrote:
* Mike Galbraith [EMAIL PROTECTED] wrote:
I see no real difference between the two assertions. Nice is just a
mechanism to set priority, so I applied your assertion to a different
range of priorities than nice covers, and returned it to
On Thu, 2007-03-01 at 22:13 +1100, Con Kolivas wrote:
if then there should be a mechanism /in the hardware/ to set the
priority of a CPU - and then the hardware could decide how to prioritize
between siblings. Doing this in software is really hard.
And that's the depressing part because
On Thursday 01 March 2007 22:33, Thomas Gleixner wrote:
On Thu, 2007-03-01 at 22:13 +1100, Con Kolivas wrote:
if then there should be a mechanism /in the hardware/ to set the
priority of a CPU - and then the hardware could decide how to
prioritize between siblings. Doing this in software
On Thu, 2007-03-01 at 23:05 +1100, Con Kolivas wrote:
And that's the depressing part because of course I was interested in that
as the original approach to the problem (and it was a big problem). When
I spoke to Intel and AMD (of course to date no SMT AMD chip exists) at
kernel summit
* Con Kolivas [EMAIL PROTECTED] wrote:
[...] Even though I'm finding myself defending code that has already
been softly tagged for redundancy, let's be clear here; we're talking
about at most a further 70ms delay in scheduling a niced task in the
presence of a nice 0 task, which is a
On Friday 02 March 2007 00:30, Ingo Molnar wrote:
* Con Kolivas [EMAIL PROTECTED] wrote:
[...] Even though I'm finding myself defending code that has already
been softly tagged for redundancy, let's be clear here; we're talking
about at most a further 70ms delay in scheduling a niced task
On Thu, 2007-03-01 at 09:01 +1100, Con Kolivas wrote:
> On Wednesday 28 February 2007 15:21, Mike Galbraith wrote:
> > On Wed, 2007-02-28 at 09:58 +1100, Con Kolivas wrote:
> > > On Tuesday 27 February 2007 19:54, Mike Galbraith wrote:
> > > > Agreed.
> > > >
> > > > I was recently looking at
On Wednesday 28 February 2007 15:21, Mike Galbraith wrote:
> (hrmph. having to copy/paste/try again. evolution seems to be broken..
> RCPT TO <[EMAIL PROTECTED]> failed: Cannot resolve your domain
> {mp049} ..caused me to be unable to send despite receipts being disabled)
Apologies for mangling
On Wednesday 28 February 2007 15:21, Mike Galbraith wrote:
(hrmph. having to copy/paste/try again. evolution seems to be broken..
RCPT TO [EMAIL PROTECTED] failed: Cannot resolve your domain
{mp049} ..caused me to be unable to send despite receipts being disabled)
Apologies for mangling the
On Thu, 2007-03-01 at 09:01 +1100, Con Kolivas wrote:
On Wednesday 28 February 2007 15:21, Mike Galbraith wrote:
On Wed, 2007-02-28 at 09:58 +1100, Con Kolivas wrote:
On Tuesday 27 February 2007 19:54, Mike Galbraith wrote:
Agreed.
I was recently looking at that spot because I
(hrmph. having to copy/paste/try again. evolution seems to be broken..
RCPT TO <[EMAIL PROTECTED]> failed: Cannot resolve your domain {mp049}
..caused me to be unable to send despite receipts being disabled)
On Wed, 2007-02-28 at 09:58 +1100, Con Kolivas wrote:
> On Tuesday 27 February 2007
Apologies for the resend, lkml address got mangled...
On Tuesday 27 February 2007 19:54, Mike Galbraith wrote:
> On Tue, 2007-02-27 at 09:33 +0100, Ingo Molnar wrote:
> > * Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> > > Thomas Gleixner napisał(a):
> > > > Adrian,
> > > >
> > > > On Mon,
On Tue, 2007-02-27 at 09:33 +0100, Ingo Molnar wrote:
> * Michal Piotrowski <[EMAIL PROTECTED]> wrote:
>
> > Thomas Gleixner napisał(a):
> > > Adrian,
> > >
> > > On Mon, 2007-02-26 at 23:05 +0100, Adrian Bunk wrote:
> > >> Subject: kernel BUG at kernel/time/tick-sched.c:168 (CONFIG_NO_HZ)
* Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Thomas Gleixner napisał(a):
> > Adrian,
> >
> > On Mon, 2007-02-26 at 23:05 +0100, Adrian Bunk wrote:
> >> Subject: kernel BUG at kernel/time/tick-sched.c:168 (CONFIG_NO_HZ)
> >> References : http://lkml.org/lkml/2007/2/16/346
> >> Submitter
Michal Piotrowski napisał(a):
> Thomas Gleixner napisał(a):
>> Adrian,
>>
>> On Mon, 2007-02-26 at 23:05 +0100, Adrian Bunk wrote:
>>> Subject: kernel BUG at kernel/time/tick-sched.c:168 (CONFIG_NO_HZ)
>>> References : http://lkml.org/lkml/2007/2/16/346
>>> Submitter : Michal Piotrowski
Thomas Gleixner napisał(a):
> Adrian,
>
> On Mon, 2007-02-26 at 23:05 +0100, Adrian Bunk wrote:
>> Subject: kernel BUG at kernel/time/tick-sched.c:168 (CONFIG_NO_HZ)
>> References : http://lkml.org/lkml/2007/2/16/346
>> Submitter : Michal Piotrowski <[EMAIL PROTECTED]>
>> Handled-By :
Adrian,
On Mon, 2007-02-26 at 23:05 +0100, Adrian Bunk wrote:
> Subject: kernel BUG at kernel/time/tick-sched.c:168 (CONFIG_NO_HZ)
> References : http://lkml.org/lkml/2007/2/16/346
> Submitter : Michal Piotrowski <[EMAIL PROTECTED]>
> Handled-By : Thomas Gleixner <[EMAIL PROTECTED]>
>
Adrian,
On Mon, 2007-02-26 at 23:05 +0100, Adrian Bunk wrote:
Subject: kernel BUG at kernel/time/tick-sched.c:168 (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/16/346
Submitter : Michal Piotrowski [EMAIL PROTECTED]
Handled-By : Thomas Gleixner [EMAIL PROTECTED]
Status :
Thomas Gleixner napisał(a):
Adrian,
On Mon, 2007-02-26 at 23:05 +0100, Adrian Bunk wrote:
Subject: kernel BUG at kernel/time/tick-sched.c:168 (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/16/346
Submitter : Michal Piotrowski [EMAIL PROTECTED]
Handled-By : Thomas Gleixner
Michal Piotrowski napisał(a):
Thomas Gleixner napisał(a):
Adrian,
On Mon, 2007-02-26 at 23:05 +0100, Adrian Bunk wrote:
Subject: kernel BUG at kernel/time/tick-sched.c:168 (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/16/346
Submitter : Michal Piotrowski [EMAIL PROTECTED]
* Michal Piotrowski [EMAIL PROTECTED] wrote:
Thomas Gleixner napisał(a):
Adrian,
On Mon, 2007-02-26 at 23:05 +0100, Adrian Bunk wrote:
Subject: kernel BUG at kernel/time/tick-sched.c:168 (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/16/346
Submitter : Michal
On Tue, 2007-02-27 at 09:33 +0100, Ingo Molnar wrote:
* Michal Piotrowski [EMAIL PROTECTED] wrote:
Thomas Gleixner napisał(a):
Adrian,
On Mon, 2007-02-26 at 23:05 +0100, Adrian Bunk wrote:
Subject: kernel BUG at kernel/time/tick-sched.c:168 (CONFIG_NO_HZ)
References :
Apologies for the resend, lkml address got mangled...
On Tuesday 27 February 2007 19:54, Mike Galbraith wrote:
On Tue, 2007-02-27 at 09:33 +0100, Ingo Molnar wrote:
* Michal Piotrowski [EMAIL PROTECTED] wrote:
Thomas Gleixner napisał(a):
Adrian,
On Mon, 2007-02-26 at 23:05
(hrmph. having to copy/paste/try again. evolution seems to be broken..
RCPT TO [EMAIL PROTECTED] failed: Cannot resolve your domain {mp049}
..caused me to be unable to send despite receipts being disabled)
On Wed, 2007-02-28 at 09:58 +1100, Con Kolivas wrote:
On Tuesday 27 February 2007 19:54,
This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm
This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm
34 matches
Mail list logo
