Hi,
I wanted to check in with you, did you receive my email from last week?
I want to share a proven system with you.
This system allows you to try the whole thing for f.r_ee for 30 days.
You can finally change your future without giving up any sensitive
information in advance.
I s-ig-ned up
Hi,
I wanted to check in with you, did you receive my email from last week?
I want to share a proven system with you.
This system allows you to try the whole thing for f.r_ee for 30 days.
You can finally change your future without giving up any sensitive
information in advance.
I s-ig-ned up
Jarek Poplawski wrote:
On 16-10-2007 03:16, Peter Williams wrote:
...
I'd suggest that we modify sched_rr_get_interval() to return -EINVAL
(with *interval set to zero) if the target task is not SCHED_RR. That
way we can save a lot of unnecessary code. I'll work on a patch.
...
I like
Jarek Poplawski wrote:
On 16-10-2007 03:16, Peter Williams wrote:
...
I'd suggest that we modify sched_rr_get_interval() to return -EINVAL
(with *interval set to zero) if the target task is not SCHED_RR. That
way we can save a lot of unnecessary code. I'll work on a patch.
...
I like
Jarek Poplawski wrote:
On 13-10-2007 03:29, Peter Williams wrote:
Jarek Poplawski wrote:
On 12-10-2007 00:23, Peter Williams wrote:
...
The reason I was going that route was for modularity (which helps
when adding plugsched patches). I'll submit a revised patch for
consideration.
...
IMHO
Jarek Poplawski wrote:
On 13-10-2007 03:29, Peter Williams wrote:
Jarek Poplawski wrote:
On 12-10-2007 00:23, Peter Williams wrote:
...
The reason I was going that route was for modularity (which helps
when adding plugsched patches). I'll submit a revised patch for
consideration.
...
IMHO
Jarek Poplawski wrote:
On 12-10-2007 00:23, Peter Williams wrote:
...
The reason I was going that route was for modularity (which helps when
adding plugsched patches). I'll submit a revised patch for consideration.
...
IMHO, it looks like modularity could suck here:
+static unsigned int
Jarek Poplawski wrote:
On 12-10-2007 00:23, Peter Williams wrote:
...
The reason I was going that route was for modularity (which helps when
adding plugsched patches). I'll submit a revised patch for consideration.
...
IMHO, it looks like modularity could suck here:
+static unsigned int
Dmitry Adamushko wrote:
On 11/10/2007, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Peter Williams <[EMAIL PROTECTED]> wrote:
-#define MIN_TIMESLICEmax(5 * HZ / 1000, 1)
-#define DEF_TIMESLICE(100 * HZ / 1000)
hm, this got removed by Dmitry quite s
and in the process moves all the code
associated with static_prio_timeslice() to sched_rt.c which is the only
place where it now has relevance.
Signed-off-by: Peter Williams <[EMAIL PROTECTED]>
Peter
--
Peter Williams [EMAIL PROTECTED]
"Learning,
non urgent) patch that I sent on the 15th of August has been applied.
Signed-off-by: Peter Williams <[EMAIL PROTECTED]>
Peter
--
Peter Williams [EMAIL PROTECTED]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bier
) patch that I sent on the 15th of August has been applied.
Signed-off-by: Peter Williams [EMAIL PROTECTED]
Peter
--
Peter Williams [EMAIL PROTECTED]
Learning, n. The kind of ignorance distinguishing the studious.
-- Ambrose Bierce
diff -r df69cb019596 include
and in the process moves all the code
associated with static_prio_timeslice() to sched_rt.c which is the only
place where it now has relevance.
Signed-off-by: Peter Williams [EMAIL PROTECTED]
Peter
--
Peter Williams [EMAIL PROTECTED]
Learning, n. The kind of ignorance
Dmitry Adamushko wrote:
On 11/10/2007, Ingo Molnar [EMAIL PROTECTED] wrote:
* Peter Williams [EMAIL PROTECTED] wrote:
-#define MIN_TIMESLICEmax(5 * HZ / 1000, 1)
-#define DEF_TIMESLICE(100 * HZ / 1000)
hm, this got removed by Dmitry quite some time ago. Could
Ingo Molnar wrote:
* Peter Williams <[EMAIL PROTECTED]> wrote:
At the moment, balance_tasks() provides low level functionality for
both
move_tasks() and move_one_task() (indirectly) via the load_balance()
function (in the sched_class interface) which also provides dual
functio
Ingo Molnar wrote:
* Peter Williams [EMAIL PROTECTED] wrote:
At the moment, balance_tasks() provides low level functionality for
both
move_tasks() and move_one_task() (indirectly) via the load_balance()
function (in the sched_class interface) which also provides dual
functionality
of the kernel.
Signed-off-by: Peter Williams <[EMAIL PROTECTED]>
Peter
--
Peter Williams [EMAIL PROTECTED]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
diff -r 90691a597f06 include/linux/sched.h
--- a/include/l
of the kernel.
Signed-off-by: Peter Williams [EMAIL PROTECTED]
Peter
--
Peter Williams [EMAIL PROTECTED]
Learning, n. The kind of ignorance distinguishing the studious.
-- Ambrose Bierce
diff -r 90691a597f06 include/linux/sched.h
--- a/include/linux/sched.h Mon Aug 13
) if CONFIG_FAIR_GROUP_SCHED is set. This should
preserve the effect of helping spread groups' higher priority tasks
around the available CPUs while improving system performance when
CONFIG_FAIR_GROUP_SCHED isn't set.
Signed-off-by: Peter Williams <[EMAIL PROTECTED]>
Peter
--
Peter Wi
) if CONFIG_FAIR_GROUP_SCHED is set. This should
preserve the effect of helping spread groups' higher priority tasks
around the available CPUs while improving system performance when
CONFIG_FAIR_GROUP_SCHED isn't set.
Signed-off-by: Peter Williams [EMAIL PROTECTED]
Peter
--
Peter Williams
.
Is it correct?
Peter
--
Peter Williams [EMAIL PROTECTED]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
.
Is it correct?
Peter
--
Peter Williams [EMAIL PROTECTED]
Learning, n. The kind of ignorance distinguishing the studious.
-- Ambrose Bierce
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
).
NB Since move_tasks() gets called with two run queue locks held even
small reductions in overhead are worthwhile.
Signed-off-by: Peter Williams <[EMAIL PROTECTED]>
--
Peter Williams [EMAIL PROTECTED]
"Learning, n. The kind of ignorance dis
).
NB Since move_tasks() gets called with two run queue locks held even
small reductions in overhead are worthwhile.
Signed-off-by: Peter Williams [EMAIL PROTECTED]
--
Peter Williams [EMAIL PROTECTED]
Learning, n. The kind of ignorance distinguishing the studious
-by: Peter Williams <[EMAIL PROTECTED]>
--
Peter Williams [EMAIL PROTECTED]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
diff -r 622a128d084b kernel/sched.c
--- a/kernel/sched.c Mon Jul 30 21:54:37 2007 -0700
+++
-by: Peter Williams [EMAIL PROTECTED]
--
Peter Williams [EMAIL PROTECTED]
Learning, n. The kind of ignorance distinguishing the studious.
-- Ambrose Bierce
diff -r 622a128d084b kernel/sched.c
--- a/kernel/sched.c Mon Jul 30 21:54:37 2007 -0700
+++ b/kernel/sched.c Thu
I've just been reviewing these patches and have spotted a couple of
errors that look like they were caused by fuzz during the patch process.
A patch that corrects the errors is attached.
Cheers
Peter
--
Peter Williams [EMAIL PROTECTED]
"Learning, n. The
I've just been reviewing these patches and have spotted a couple of
errors that look like they were caused by fuzz during the patch process.
A patch that corrects the errors is attached.
Cheers
Peter
--
Peter Williams [EMAIL PROTECTED]
Learning, n. The kind
Ingo Molnar wrote:
> * Peter Williams <[EMAIL PROTECTED]> wrote:
>
>> Probably the last one now that CFS is in the main line :-(.
>
> hm, why is CFS in mainline a problem?
It means a major rewrite of the plugsched interface and I'm not sure
that it's worth it (if CFS wor
Ingo Molnar wrote:
* Peter Williams [EMAIL PROTECTED] wrote:
Probably the last one now that CFS is in the main line :-(.
hm, why is CFS in mainline a problem?
It means a major rewrite of the plugsched interface and I'm not sure
that it's worth it (if CFS works well). However, note that I
Gene Heskett wrote:
> On Friday 13 July 2007, Peter Williams wrote:
>> Ingo Molnar wrote:
>>> * Gregory Haskins <[EMAIL PROTECTED]> wrote:
>>>> On Thu, 2007-07-12 at 14:07 +0200, Ingo Molnar wrote:
>>>>> * Gregory Haskins <[EMAIL PROTECTED]>
nd it extremely valuable to be able to bisect this
>> beast while working on the 21-22 port.
>
> we are working on something in this area :) Stay tuned ...
I've just been reviewing these patches and have spotted an error in the
file mm/slob.c at lines 500-501 whereby a non existent varia
and have spotted an error in the
file mm/slob.c at lines 500-501 whereby a non existent variable c is
referenced. The attached patch is a proposed fix to the problem.
--
Peter Williams [EMAIL PROTECTED]
Learning, n. The kind of ignorance distinguishing the studious
Gene Heskett wrote:
On Friday 13 July 2007, Peter Williams wrote:
Ingo Molnar wrote:
* Gregory Haskins [EMAIL PROTECTED] wrote:
On Thu, 2007-07-12 at 14:07 +0200, Ingo Molnar wrote:
* Gregory Haskins [EMAIL PROTECTED] wrote:
Hi Ingo, Thomas, and the greater linux-rt community,
I just
eduler will be ingosched (which is the normal scheduler).
The scheduler in force on a running system can be determined by the
contents of:
/proc/scheduler
Control parameters for the scheduler can be read/set via files in:
/sys/cpusched//
Peter
--
Peter Williams
scheduler will be ingosched (which is the normal scheduler).
The scheduler in force on a running system can be determined by the
contents of:
/proc/scheduler
Control parameters for the scheduler can be read/set via files in:
/sys/cpusched/scheduler/
Peter
--
Peter Williams
Siddha, Suresh B wrote:
On Tue, May 29, 2007 at 07:18:18PM -0700, Peter Williams wrote:
Siddha, Suresh B wrote:
I can try 32-bit kernel to check.
Don't bother. I just checked 2.6.22-rc3 and the problem is not present
which means something between rc2 and rc3 has fixed the problem. I hate
Siddha, Suresh B wrote:
On Tue, May 29, 2007 at 07:18:18PM -0700, Peter Williams wrote:
Siddha, Suresh B wrote:
I can try 32-bit kernel to check.
Don't bother. I just checked 2.6.22-rc3 and the problem is not present
which means something between rc2 and rc3 has fixed the problem. I hate
Siddha, Suresh B wrote:
On Tue, May 29, 2007 at 07:18:18PM -0700, Peter Williams wrote:
Siddha, Suresh B wrote:
I can try 32-bit kernel to check.
Don't bother. I just checked 2.6.22-rc3 and the problem is not present
which means something between rc2 and rc3 has fixed the problem. I hate
Siddha, Suresh B wrote:
On Tue, May 29, 2007 at 07:18:18PM -0700, Peter Williams wrote:
Siddha, Suresh B wrote:
I can try 32-bit kernel to check.
Don't bother. I just checked 2.6.22-rc3 and the problem is not present
which means something between rc2 and rc3 has fixed the problem. I hate
William Lee Irwin III wrote:
On Wed, May 30, 2007 at 10:09:28AM +1000, Peter Williams wrote:
So what you're saying is that you think dynamic priority (or its
equivalent) should be used for load balancing instead of static priority?
It doesn't do much in other schemes, but when fairness
Siddha, Suresh B wrote:
On Tue, May 29, 2007 at 04:54:29PM -0700, Peter Williams wrote:
I tried with various refresh rates of top too.. Do you see the issue
at runlevel 3 too?
I haven't tried that.
Do your spinners ever relinquish the CPU voluntarily?
Nope. Simple and plain while(1); 's
I
William Lee Irwin III wrote:
William Lee Irwin III wrote:
Lag should be considered in lieu of load because lag
On Sun, May 27, 2007 at 11:29:51AM +1000, Peter Williams wrote:
What's the definition of lag here?
Lag is the deviation of a task's allocated CPU time from the CPU time
it would
Siddha, Suresh B wrote:
On Thu, May 24, 2007 at 04:23:19PM -0700, Peter Williams wrote:
Siddha, Suresh B wrote:
On Thu, May 24, 2007 at 12:43:58AM -0700, Peter Williams wrote:
Further testing indicates that CONFIG_SCHED_MC is not implicated and
it's CONFIG_SCHED_SMT that's causing the problem
Siddha, Suresh B wrote:
On Thu, May 24, 2007 at 04:23:19PM -0700, Peter Williams wrote:
Siddha, Suresh B wrote:
On Thu, May 24, 2007 at 12:43:58AM -0700, Peter Williams wrote:
Further testing indicates that CONFIG_SCHED_MC is not implicated and
it's CONFIG_SCHED_SMT that's causing the problem
William Lee Irwin III wrote:
William Lee Irwin III wrote:
Lag should be considered in lieu of load because lag
On Sun, May 27, 2007 at 11:29:51AM +1000, Peter Williams wrote:
What's the definition of lag here?
Lag is the deviation of a task's allocated CPU time from the CPU time
it would
Siddha, Suresh B wrote:
On Tue, May 29, 2007 at 04:54:29PM -0700, Peter Williams wrote:
I tried with various refresh rates of top too.. Do you see the issue
at runlevel 3 too?
I haven't tried that.
Do your spinners ever relinquish the CPU voluntarily?
Nope. Simple and plain while(1); 's
I
William Lee Irwin III wrote:
On Wed, May 30, 2007 at 10:09:28AM +1000, Peter Williams wrote:
So what you're saying is that you think dynamic priority (or its
equivalent) should be used for load balancing instead of static priority?
It doesn't do much in other schemes, but when fairness
Peter Williams wrote:
Srivatsa Vaddagiri wrote:
On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote:
I don't think that ignoring cpu affinity is an option. Setting the
cpu affinity of tasks is a deliberate policy action on the part of
the system administrator and has
Srivatsa Vaddagiri wrote:
On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote:
I don't think that ignoring cpu affinity is an option. Setting the cpu
affinity of tasks is a deliberate policy action on the part of the
system administrator and has to be honoured.
mmm ..but users
Srivatsa Vaddagiri wrote:
On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote:
I don't think that ignoring cpu affinity is an option. Setting the cpu
affinity of tasks is a deliberate policy action on the part of the
system administrator and has to be honoured.
mmm ..but users
Peter Williams wrote:
Srivatsa Vaddagiri wrote:
On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote:
I don't think that ignoring cpu affinity is an option. Setting the
cpu affinity of tasks is a deliberate policy action on the part of
the system administrator and has
William Lee Irwin III wrote:
Srivatsa Vaddagiri wrote:
Ingo/Peter, any thoughts here? CFS and smpnice probably is "broken"
with respect to such example as above albeit for nice-based tasks.
On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote:
See above. I think
William Lee Irwin III wrote:
Srivatsa Vaddagiri wrote:
Ingo/Peter, any thoughts here? CFS and smpnice probably is broken
with respect to such example as above albeit for nice-based tasks.
On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote:
See above. I think that faced with cpu
run queue and using that to modify find_busiest_group() and
find_busiest_queue() to be a bit smarter. But I'm not sure that it
would be worth the added complexity.
Peter
--
Peter Williams [EMAIL PROTECTED]
"Learning, n. The kind of ignorance distinguishing t
that to modify find_busiest_group() and
find_busiest_queue() to be a bit smarter. But I'm not sure that it
would be worth the added complexity.
Peter
--
Peter Williams [EMAIL PROTECTED]
Learning, n. The kind of ignorance distinguishing the studious.
-- Ambrose Bierce
Siddha, Suresh B wrote:
On Thu, May 24, 2007 at 12:43:58AM -0700, Peter Williams wrote:
Peter Williams wrote:
The relevant code, find_busiest_group() and find_busiest_queue(), has a
lot of code that is ifdefed by CONFIG_SCHED_MC and CONFIG_SCHED_SMT and,
as these macros were defined
Peter Williams wrote:
Peter Williams wrote:
Peter Williams wrote:
Dmitry Adamushko wrote:
On 18/05/07, Peter Williams <[EMAIL PROTECTED]> wrote:
[...]
One thing that might work is to jitter the load balancing interval a
bit. The reason I say this is that one of the characteristics
Peter Williams wrote:
Peter Williams wrote:
Peter Williams wrote:
Dmitry Adamushko wrote:
On 18/05/07, Peter Williams [EMAIL PROTECTED] wrote:
[...]
One thing that might work is to jitter the load balancing interval a
bit. The reason I say this is that one of the characteristics of top
Siddha, Suresh B wrote:
On Thu, May 24, 2007 at 12:43:58AM -0700, Peter Williams wrote:
Peter Williams wrote:
The relevant code, find_busiest_group() and find_busiest_queue(), has a
lot of code that is ifdefed by CONFIG_SCHED_MC and CONFIG_SCHED_SMT and,
as these macros were defined
Dmitry Adamushko wrote:
On 22/05/07, Peter Williams <[EMAIL PROTECTED]> wrote:
> [...]
> Hum.. I guess, a 0/4 scenario wouldn't fit well in this explanation..
No, and I haven't seen one.
Well, I just took one of your calculated probabilities as something
you have really observed
Peter Williams wrote:
Peter Williams wrote:
Dmitry Adamushko wrote:
On 18/05/07, Peter Williams <[EMAIL PROTECTED]> wrote:
[...]
One thing that might work is to jitter the load balancing interval a
bit. The reason I say this is that one of the characteristics of top
and g
Dmitry Adamushko wrote:
On 22/05/07, Peter Williams [EMAIL PROTECTED] wrote:
[...]
Hum.. I guess, a 0/4 scenario wouldn't fit well in this explanation..
No, and I haven't seen one.
Well, I just took one of your calculated probabilities as something
you have really observed - (*) below
Peter Williams wrote:
Peter Williams wrote:
Dmitry Adamushko wrote:
On 18/05/07, Peter Williams [EMAIL PROTECTED] wrote:
[...]
One thing that might work is to jitter the load balancing interval a
bit. The reason I say this is that one of the characteristics of top
and gkrellm
Peter Williams wrote:
Dmitry Adamushko wrote:
On 18/05/07, Peter Williams <[EMAIL PROTECTED]> wrote:
[...]
One thing that might work is to jitter the load balancing interval a
bit. The reason I say this is that one of the characteristics of top
and gkrellm is that they run at a more o
Dmitry Adamushko wrote:
On 18/05/07, Peter Williams <[EMAIL PROTECTED]> wrote:
[...]
One thing that might work is to jitter the load balancing interval a
bit. The reason I say this is that one of the characteristics of top
and gkrellm is that they run at a more or less constant in
Dmitry Adamushko wrote:
On 18/05/07, Peter Williams [EMAIL PROTECTED] wrote:
[...]
One thing that might work is to jitter the load balancing interval a
bit. The reason I say this is that one of the characteristics of top
and gkrellm is that they run at a more or less constant interval
Peter Williams wrote:
Dmitry Adamushko wrote:
On 18/05/07, Peter Williams [EMAIL PROTECTED] wrote:
[...]
One thing that might work is to jitter the load balancing interval a
bit. The reason I say this is that one of the characteristics of top
and gkrellm is that they run at a more or less
Dmitry Adamushko wrote:
On 18/05/07, Peter Williams <[EMAIL PROTECTED]> wrote:
[...]
One thing that might work is to jitter the load balancing interval a
bit. The reason I say this is that one of the characteristics of top
and gkrellm is that they run at a more or less constant in
Dmitry Adamushko wrote:
On 18/05/07, Peter Williams [EMAIL PROTECTED] wrote:
[...]
One thing that might work is to jitter the load balancing interval a
bit. The reason I say this is that one of the characteristics of top
and gkrellm is that they run at a more or less constant interval
Peter Williams wrote:
Ingo Molnar wrote:
* Peter Williams <[EMAIL PROTECTED]> wrote:
I've now done this test on a number of kernels: 2.6.21 and 2.6.22-rc1
with and without CFS; and the problem is always present. It's not
"nice" related as the all four tasks are run at nice =
Ingo Molnar wrote:
* Peter Williams <[EMAIL PROTECTED]> wrote:
I've now done this test on a number of kernels: 2.6.21 and 2.6.22-rc1
with and without CFS; and the problem is always present. It's not
"nice" related as the all four tasks are run at nice == 0.
could you
Ingo Molnar wrote:
* Peter Williams [EMAIL PROTECTED] wrote:
I've now done this test on a number of kernels: 2.6.21 and 2.6.22-rc1
with and without CFS; and the problem is always present. It's not
nice related as the all four tasks are run at nice == 0.
could you try -v13 and did
Peter Williams wrote:
Ingo Molnar wrote:
* Peter Williams [EMAIL PROTECTED] wrote:
I've now done this test on a number of kernels: 2.6.21 and 2.6.22-rc1
with and without CFS; and the problem is always present. It's not
nice related as the all four tasks are run at nice == 0.
could you try
Ingo Molnar wrote:
* Peter Williams <[EMAIL PROTECTED]> wrote:
Load balancing appears to be badly broken in this version. When I
started 4 hard spinners on my 2 CPU machine one ended up on one CPU
and the other 3 on the other CPU and they stayed there.
could you try to debug this
Ingo Molnar wrote:
* Peter Williams [EMAIL PROTECTED] wrote:
Load balancing appears to be badly broken in this version. When I
started 4 hard spinners on my 2 CPU machine one ended up on one CPU
and the other 3 on the other CPU and they stayed there.
could you try to debug this a bit more
Ingo Molnar wrote:
* Peter Williams <[EMAIL PROTECTED]> wrote:
As usual, any sort of feedback, bugreport, fix and suggestion is more
than welcome,
Load balancing appears to be badly broken in this version. When I
started 4 hard spinners on my 2 CPU machine one ended up on o
Ingo Molnar wrote:
* Peter Williams [EMAIL PROTECTED] wrote:
As usual, any sort of feedback, bugreport, fix and suggestion is more
than welcome,
Load balancing appears to be badly broken in this version. When I
started 4 hard spinners on my 2 CPU machine one ended up on one CPU
other CPU and they stayed there.
Peter
--
Peter Williams [EMAIL PROTECTED]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
and they stayed there.
Peter
--
Peter Williams [EMAIL PROTECTED]
Learning, n. The kind of ignorance distinguishing the studious.
-- Ambrose Bierce
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Esben Nielsen wrote:
On Tue, 8 May 2007, Peter Williams wrote:
Esben Nielsen wrote:
On Sun, 6 May 2007, Linus Torvalds wrote:
> > > On Sun, 6 May 2007, Ingo Molnar wrote:
> > > > * Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > > > >
Esben Nielsen wrote:
On Tue, 8 May 2007, Peter Williams wrote:
Esben Nielsen wrote:
On Sun, 6 May 2007, Linus Torvalds wrote:
On Sun, 6 May 2007, Ingo Molnar wrote:
* Linus Torvalds [EMAIL PROTECTED] wrote:
So the _only_ valid way to handle timers is to
- either
iting time values to that value would not
break anything.
Except if you're measuring sleep times. I think that you'll find lots
of tasks sleep for more than 72 minutes.
Peter
--
Peter Williams [EMAIL PROTECTED]
"Learning, n. The kind of ignorance disting
sleep for more than 72 minutes.
Peter
--
Peter Williams [EMAIL PROTECTED]
Learning, n. The kind of ignorance distinguishing the studious.
-- Ambrose Bierce
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
l parameters for the scheduler can be read/set via files in:
/sys/cpusched//
Peter
--
Peter Williams [EMAIL PROTECTED]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
To unsubscribe from this list: send the line &qu
parameters for the scheduler can be read/set via files in:
/sys/cpusched/scheduler/
Peter
--
Peter Williams [EMAIL PROTECTED]
Learning, n. The kind of ignorance distinguishing the studious.
-- Ambrose Bierce
-
To unsubscribe from this list: send the line
Neil Horman wrote:
On Sat, Apr 28, 2007 at 12:28:28AM +1000, Peter Williams wrote:
Neil Horman wrote:
On Fri, Apr 27, 2007 at 04:05:11PM +1000, Peter Williams wrote:
Damn, This is what happens when I try to do things too quickly. I missed one
spot in my last patch where I replaced skb
Neil Horman wrote:
On Fri, Apr 27, 2007 at 04:05:11PM +1000, Peter Williams wrote:
Linus Torvalds wrote:
On Fri, 27 Apr 2007, Peter Williams wrote:
The 2.6.21 kernel is hanging during the post boot phase where various
daemons
are being started (not always the same daemon unfortunately
Linus Torvalds wrote:
On Fri, 27 Apr 2007, Peter Williams wrote:
The 2.6.21 kernel is hanging during the post boot phase where various daemons
are being started (not always the same daemon unfortunately).
This problem was not present in 2.6.21-rc7 and there is no oops or other
unusual output
Linus Torvalds wrote:
On Fri, 27 Apr 2007, Peter Williams wrote:
The 2.6.21 kernel is hanging during the post boot phase where various daemons
are being started (not always the same daemon unfortunately).
This problem was not present in 2.6.21-rc7 and there is no oops or other
unusual output
Neil Horman wrote:
On Fri, Apr 27, 2007 at 04:05:11PM +1000, Peter Williams wrote:
Linus Torvalds wrote:
On Fri, 27 Apr 2007, Peter Williams wrote:
The 2.6.21 kernel is hanging during the post boot phase where various
daemons
are being started (not always the same daemon unfortunately
Neil Horman wrote:
On Sat, Apr 28, 2007 at 12:28:28AM +1000, Peter Williams wrote:
Neil Horman wrote:
On Fri, Apr 27, 2007 at 04:05:11PM +1000, Peter Williams wrote:
Damn, This is what happens when I try to do things too quickly. I missed one
spot in my last patch where I replaced skb
Linus Torvalds wrote:
On Fri, 27 Apr 2007, Peter Williams wrote:
The 2.6.21 kernel is hanging during the post boot phase where various daemons
are being started (not always the same daemon unfortunately).
This problem was not present in 2.6.21-rc7 and there is no oops or other
unusual output
Linus Torvalds wrote:
On Fri, 27 Apr 2007, Peter Williams wrote:
The 2.6.21 kernel is hanging during the post boot phase where various daemons
are being started (not always the same daemon unfortunately).
This problem was not present in 2.6.21-rc7 and there is no oops or other
unusual output
.
Of course, I could (very likely!) be full of it! ;-)
And won't be using the any new scheduler on these computers anyhow as
that would involve bringing the system down to install the new kernel. :-)
Peter
--
Peter Williams [EMAIL PROTECTED]
"Learning, n. The
pler ways to give X more CPU if it needs
it. However, I think there's something seriously wrong if it needs the
-19 nice that I've heard mentioned. You might as well just run it as a
real time process.
Peter
--
Peter Williams [EMAIL PROTECTED]
"Learning, n. The
think there's something seriously wrong if it needs the
-19 nice that I've heard mentioned. You might as well just run it as a
real time process.
Peter
--
Peter Williams [EMAIL PROTECTED]
Learning, n. The kind of ignorance distinguishing the studious
.
Of course, I could (very likely!) be full of it! ;-)
And won't be using the any new scheduler on these computers anyhow as
that would involve bringing the system down to install the new kernel. :-)
Peter
--
Peter Williams [EMAIL PROTECTED]
Learning, n. The kind
because the O(1) tried this model and failed doesn't mean that the
model is bad. O(1) was a flawed implementation of a good model.
Peter
PS Doing a kernel build in an xterm isn't an example of high enough
output to cause a problem as (on my system) it only raises X's
consumption from 0 to 2% to 2 to
.
Peter
PS Doing a kernel build in an xterm isn't an example of high enough
output to cause a problem as (on my system) it only raises X's
consumption from 0 to 2% to 2 to 5%. The type of output that causes the
problem is usually flying past too fast to read.
--
Peter Williams
1 - 100 of 328 matches
Mail list logo
