On Sun, Jul 20, 2008 at 7:13 AM, Kris Kennaway <[EMAIL PROTECTED]> wrote:
> Murty, Ravi wrote:
>>
>> Jeremy, thanks. I look forward to switching to ULE in 7.0 and realize
>> that it is a completely new scheduler (I spent some time yesterday
>> looking at it) -- which is my porting effort is much ha
Murty, Ravi wrote:
Jeremy, thanks. I look forward to switching to ULE in 7.0 and realize
that it is a completely new scheduler (I spent some time yesterday
looking at it) -- which is my porting effort is much harder than a
simple cut and paste. I just wanted to find out if there was something
sim
hanks
Ravi
-Original Message-
From: Jeremy Chadwick [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 20, 2008 6:59 AM
To: Murty, Ravi
Cc: Kris Kennaway; [EMAIL PROTECTED]; freebsd-hackers@freebsd.org
Subject: Re: Bug in calcru in he 6.2 and 6.3 kernels
On Sun, Jul 20, 2008 at 06:51:22AM -0700, Murty,
On Sun, Jul 20, 2008 at 06:51:22AM -0700, Murty, Ravi wrote:
> Has anyone identified the issue(s) that might be broken in the ULE
> scheduler in 6.2? I am running a rather simple test - creates 8 threads
> and runs it on an 8 CPU system (not a whole lot running on the system).
> When I run it with
might be going on in 6.2 before I spend the time to migrate to 7.0.
Thanks
Ravi
-Original Message-
From: Kris Kennaway [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2008 2:04 PM
To: [EMAIL PROTECTED]
Cc: Murty, Ravi; freebsd-hackers@freebsd.org
Subject: Re: Bug in calcru in he 6.
Xin LI wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kris Kennaway wrote:
| Murty, Ravi wrote:
|> Hello everyone,
|>
|>
|>
|> Finally found what my last problem was. We were running top in a loop
|> and running some workloads that called sched_bind() to bind threads to
|> specific CPUs. T
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kris Kennaway wrote:
| Murty, Ravi wrote:
|> Hello everyone,
|>
|>
|>
|> Finally found what my last problem was. We were running top in a loop
|> and running some workloads that called sched_bind() to bind threads to
|> specific CPUs. The problem was
Murty, Ravi wrote:
Hello everyone,
Finally found what my last problem was. We were running top in a loop
and running some workloads that called sched_bind() to bind threads to
specific CPUs. The problem was that (and I am using ULE) sched_bind
calls a function to notify another CPU of a thre
Hello everyone,
Finally found what my last problem was. We were running top in a loop
and running some workloads that called sched_bind() to bind threads to
specific CPUs. The problem was that (and I am using ULE) sched_bind
calls a function to notify another CPU of a thread and then mi_switche
hihi, all -
i am currently running the experiment with both suggestions - doug's one of
simply re-ordering the equations, and my more complicated one with the
conditional (and the re-ordering) - the first significant data point will come
tomorrow, when the test cpu times pass the first error thre
On 26 Jan, Chris Landauer wrote:
>
> hihi, doug -
>
>> Doug Ambrisko <[EMAIL PROTECTED]> wrote
>> ...
>> The assumption with this calculation is that st & it tend to be
>> small compared to tt so the 1024 X shouldn't overflow much.
>> ...
>> [EMAIL PROTECTED] wrote:
>> |..
hihi, doug -
> Doug Ambrisko <[EMAIL PROTECTED]> wrote
> ...
> The assumption with this calculation is that st & it tend to be
> small compared to tt so the 1024 X shouldn't overflow much.
> ...
> [EMAIL PROTECTED] wrote:
> | ...but i'm a little worried that the 1024 m
hihi, doug -
thanx for the suggestion - the notion of computing ut just with subtraction is
really good, since it is likely to be the largest of the three values in most
applications, but i'm a little worried that the 1024 multiplications aren't
large enough when tt gets really large - i'll do th
Chris Landauer writes:
| thanx for the suggestion - the notion of computing ut just with subtraction is
| really good, since it is likely to be the largest of the three values in most
| applications, but i'm a little worried that the 1024 multiplications aren't
| large enough when tt gets really la
Chris Landauer writes:
|
| hihi, all -
|
| well, i have an "almost" fix for the problem - read on, ...
| (this is for discussin before send-pr submission)
|
| description
|
| in FreeBSD 5.3-RELEASE (and 5.2.1R, and 5.1R),
| in file /usr/src/sys/kern/kern_resource.c,
| lines 65
hihi, all -
well, i have an "almost" fix for the problem - read on, ...
(this is for discussin before send-pr submission)
description
in FreeBSD 5.3-RELEASE (and 5.2.1R, and 5.1R),
in file /usr/src/sys/kern/kern_resource.c,
lines 657-750 define a function calcru(),
I believe that spl() protection is required here, in fact, that it should
be extended to cover the read of p->p_runtime as well. These are all 64
bit integers, so on IA32, the worst case is two consecutive off-by one
reads during overflow - i.e reading 0x 0x0002 instead of
0x 0
17 matches
Mail list logo
