Hi;
01 Haz 2007 Cum tarihinde, Linus Torvalds şunları yazmıştı:
> Has it been hot where you are lately? Is your fan working?
First of all sorry for late reply.
For a while İstanbul is not really hot [~26 C] :) and yes fans are/seems
working without a problem.
> Hardware that acts up under
Hi;
01 Haz 2007 Cum tarihinde, Linus Torvalds şunları yazmıştı:
Has it been hot where you are lately? Is your fan working?
First of all sorry for late reply.
For a while İstanbul is not really hot [~26 C] :) and yes fans are/seems
working without a problem.
Hardware that acts up under load
Hi, Ingo:
I am sorry for disturbing you again, I am interesting on CFS,
however, had really confused on the fairness implementation of CFS.
After reviewed the past mails of LKML, I known the virtual clock is
used by fairness measuring scale, it is excellent idea. and CFS use
Hi, Ingo:
I am sorry for disturbing you again, I am interesting on CFS,
however, had really confused on the fairness implementation of CFS.
After reviewed the past mails of LKML, I known the virtual clock is
used by fairness measuring scale, it is excellent idea. and CFS use
Ingo Molnar wrote:
* Li Yu <[EMAIL PROTECTED]> wrote:
Eh, I wrong again~ I even took an experiment in last week end, this
idea is really bad! ;(
I think the most inner of source of my wrong again and again is
misunderstanding virtual time. For more better understanding this, I
try to
* Li Yu <[EMAIL PROTECTED]> wrote:
> Eh, I wrong again~ I even took an experiment in last week end, this
> idea is really bad! ;(
>
> I think the most inner of source of my wrong again and again is
> misunderstanding virtual time. For more better understanding this, I
> try to write one
* Balbir Singh <[EMAIL PROTECTED]> wrote:
> + /*
> + * Split up sched_exec_time according to the utime and
> + * stime ratio. At this point utime contains the summed
> + * sched_exec_runtime and stime is zero
> + */
> +
* Balbir Singh [EMAIL PROTECTED] wrote:
+ /*
+ * Split up sched_exec_time according to the utime and
+ * stime ratio. At this point utime contains the summed
+ * sched_exec_runtime and stime is zero
+ */
+ if
* Li Yu [EMAIL PROTECTED] wrote:
Eh, I wrong again~ I even took an experiment in last week end, this
idea is really bad! ;(
I think the most inner of source of my wrong again and again is
misunderstanding virtual time. For more better understanding this, I
try to write one python
Ingo Molnar wrote:
* Li Yu [EMAIL PROTECTED] wrote:
Eh, I wrong again~ I even took an experiment in last week end, this
idea is really bad! ;(
I think the most inner of source of my wrong again and again is
misunderstanding virtual time. For more better understanding this, I
try to
Ingo Molnar wrote:
* Li Yu <[EMAIL PROTECTED]> wrote:
Also, I have want to know what's real meaning of
add_wait_runtime(rq, curr, delta_mine - delta_exec);
in update_curr(), IMHO, it should be
add_wait_runtime(rq, curr, delta_mine - delta_fair);
Is this just another heuristics?
Ingo Molnar wrote:
* Li Yu <[EMAIL PROTECTED]> wrote:
Also, I have want to know what's real meaning of
add_wait_runtime(rq, curr, delta_mine - delta_exec);
in update_curr(), IMHO, it should be
add_wait_runtime(rq, curr, delta_mine - delta_fair);
Is this just another heuristics?
Ingo Molnar wrote:
* Li Yu [EMAIL PROTECTED] wrote:
Also, I have want to know what's real meaning of
add_wait_runtime(rq, curr, delta_mine - delta_exec);
in update_curr(), IMHO, it should be
add_wait_runtime(rq, curr, delta_mine - delta_fair);
Is this just another heuristics? or
Ingo Molnar wrote:
* Li Yu [EMAIL PROTECTED] wrote:
Also, I have want to know what's real meaning of
add_wait_runtime(rq, curr, delta_mine - delta_exec);
in update_curr(), IMHO, it should be
add_wait_runtime(rq, curr, delta_mine - delta_fair);
Is this just another heuristics? or
* Li Yu <[EMAIL PROTECTED]> wrote:
> Also, I have want to know what's real meaning of
>
>add_wait_runtime(rq, curr, delta_mine - delta_exec);
>
> in update_curr(), IMHO, it should be
>
>add_wait_runtime(rq, curr, delta_mine - delta_fair);
>
> Is this just another heuristics? or my
[OT, thus removed private addresses]
Hi,
On Fri, Jun 01, 2007 at 04:35:02PM +0300, S.Ça??lar Onur wrote:
> Seems like this piece of hardware is dieing [For a while my laptop starts to
> poweroff suddenly without any log/error etc] and i think all these problems
> caused by this. Or at least/
On Fri, 1 Jun 2007, S.?a?lar Onur wrote:
>
> Seems like this piece of hardware is dieing [For a while my laptop starts to
> poweroff suddenly without any log/error etc] and i think all these problems
> caused by this. Or at least/ for me/ this laptop (sony vaio fs-215b) is not a
> stable
Hi;
26 May 2007 Cts tarihinde, S.Çağlar Onur şunları yazmıştı:
> Under load (compiling any Qt app. or kernel with -j1 or -j2) audio always
> goes sync with time (and i'm sure it never skips) but video starts slowdown
> and loses its sync with audio (like for the 10th sec. of a movie, audio is
>
Ingo Molnar wrote:
* Li Yu <[EMAIL PROTECTED]> wrote:
static void distribute_fair_add(struct rq *rq, s64 delta)
{
struct task_struct *curr = rq->curr;
s64 delta_fair = 0;
if (!(sysctl_sched_load_smoothing & 32))
return;
if (rq->nr_running) {
delta_fair =
Ingo Molnar wrote:
* Li Yu [EMAIL PROTECTED] wrote:
static void distribute_fair_add(struct rq *rq, s64 delta)
{
struct task_struct *curr = rq-curr;
s64 delta_fair = 0;
if (!(sysctl_sched_load_smoothing 32))
return;
if (rq-nr_running) {
delta_fair =
Hi;
26 May 2007 Cts tarihinde, S.Çağlar Onur şunları yazmıştı:
Under load (compiling any Qt app. or kernel with -j1 or -j2) audio always
goes sync with time (and i'm sure it never skips) but video starts slowdown
and loses its sync with audio (like for the 10th sec. of a movie, audio is
at
On Fri, 1 Jun 2007, S.?a?lar Onur wrote:
Seems like this piece of hardware is dieing [For a while my laptop starts to
poweroff suddenly without any log/error etc] and i think all these problems
caused by this. Or at least/ for me/ this laptop (sony vaio fs-215b) is not a
stable test bed
[OT, thus removed private addresses]
Hi,
On Fri, Jun 01, 2007 at 04:35:02PM +0300, S.Ça??lar Onur wrote:
Seems like this piece of hardware is dieing [For a while my laptop starts to
poweroff suddenly without any log/error etc] and i think all these problems
caused by this. Or at least/ for
* Li Yu [EMAIL PROTECTED] wrote:
Also, I have want to know what's real meaning of
add_wait_runtime(rq, curr, delta_mine - delta_exec);
in update_curr(), IMHO, it should be
add_wait_runtime(rq, curr, delta_mine - delta_fair);
Is this just another heuristics? or my opinion is
* Li Yu <[EMAIL PROTECTED]> wrote:
> static void distribute_fair_add(struct rq *rq, s64 delta)
> {
>struct task_struct *curr = rq->curr;
>s64 delta_fair = 0;
>
>if (!(sysctl_sched_load_smoothing & 32))
>return;
>
>if (rq->nr_running) {
>delta_fair =
static void distribute_fair_add(struct rq *rq, s64 delta)
{
struct task_struct *curr = rq->curr;
s64 delta_fair = 0;
if (!(sysctl_sched_load_smoothing & 32))
return;
if (rq->nr_running) {
delta_fair = div64_s(delta, rq->nr_running);
/*
* The currently
static void distribute_fair_add(struct rq *rq, s64 delta)
{
struct task_struct *curr = rq-curr;
s64 delta_fair = 0;
if (!(sysctl_sched_load_smoothing 32))
return;
if (rq-nr_running) {
delta_fair = div64_s(delta, rq-nr_running);
/*
* The currently
* Li Yu [EMAIL PROTECTED] wrote:
static void distribute_fair_add(struct rq *rq, s64 delta)
{
struct task_struct *curr = rq-curr;
s64 delta_fair = 0;
if (!(sysctl_sched_load_smoothing 32))
return;
if (rq-nr_running) {
delta_fair = div64_s(delta,
On Mon, May 28, 2007 at 01:07:48PM +0200, Ingo Molnar wrote:
>
> * Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> > Ingo Molnar wrote:
> > > i found an accounting bug in this: it didnt sum up threads correctly.
> > > The patch below fixes this. The stime == 0 problem is still there
> > > though.
Hi, Ingo,
> +static clock_t task_utime(struct task_struct *p)
> +{
> + /*
> + * Use CFS's precise accounting, if available:
> + */
> + if (!has_rt_policy(p) && !(sysctl_sched_load_smoothing & 128))
> + return nsec_to_clock_t(p->sum_exec_runtime);
I wonder if this
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > [...] in update_stats_enqueue(), It seem that these statements in
> > two brances of "if (p->load_weight > NICE_0_LOAD)" are same, is it
> > on purpose?
>
> what do you mean?
you are right indeed. Mike Galbraith has sent a cleanup patch that
* Li Yu <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> >i'm pleased to announce release -v14 of the CFS scheduler patchset.
> >
> >The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be
> >downloaded from the usual place:
> >
> >
* Li Yu [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
i'm pleased to announce release -v14 of the CFS scheduler patchset.
The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be
downloaded from the usual place:
http://people.redhat.com/mingo/cfs-scheduler/
I tried
* Ingo Molnar [EMAIL PROTECTED] wrote:
[...] in update_stats_enqueue(), It seem that these statements in
two brances of if (p-load_weight NICE_0_LOAD) are same, is it
on purpose?
what do you mean?
you are right indeed. Mike Galbraith has sent a cleanup patch that
removes that
Hi, Ingo,
+static clock_t task_utime(struct task_struct *p)
+{
+ /*
+ * Use CFS's precise accounting, if available:
+ */
+ if (!has_rt_policy(p) !(sysctl_sched_load_smoothing 128))
+ return nsec_to_clock_t(p-sum_exec_runtime);
I wonder if this leads to
On Mon, May 28, 2007 at 01:07:48PM +0200, Ingo Molnar wrote:
* Balbir Singh [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
i found an accounting bug in this: it didnt sum up threads correctly.
The patch below fixes this. The stime == 0 problem is still there
though.
Ingo
Li Yu wrote:
But as I observe by cat /proc/sched_debug (2.6.21.1, UP, RHEL4), I
found the all waiting fields often are more than zero, or less than zero.
IMHO, the sum of task_struct->wait_runtime just is the denominator of
all runnable time in some ways, is it right? if so, increasing the
* Balbir Singh <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> > i found an accounting bug in this: it didnt sum up threads correctly.
> > The patch below fixes this. The stime == 0 problem is still there
> > though.
> >
> > Ingo
> >
>
> Thanks! I'll test the code on Monday. I do not
* Balbir Singh [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
i found an accounting bug in this: it didnt sum up threads correctly.
The patch below fixes this. The stime == 0 problem is still there
though.
Ingo
Thanks! I'll test the code on Monday. I do not understand the
Li Yu wrote:
But as I observe by cat /proc/sched_debug (2.6.21.1, UP, RHEL4), I
found the all waiting fields often are more than zero, or less than zero.
IMHO, the sum of task_struct-wait_runtime just is the denominator of
all runnable time in some ways, is it right? if so, increasing the
Ingo Molnar wrote:
i'm pleased to announce release -v14 of the CFS scheduler patchset.
The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be
downloaded from the usual place:
http://people.redhat.com/mingo/cfs-scheduler/
In comment before distribute_fair_add(), we
Ingo Molnar wrote:
i'm pleased to announce release -v14 of the CFS scheduler patchset.
The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be
downloaded from the usual place:
http://people.redhat.com/mingo/cfs-scheduler/
In comment before distribute_fair_add(), we
Ingo Molnar wrote:
i'm pleased to announce release -v14 of the CFS scheduler patchset.
The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be
downloaded from the usual place:
http://people.redhat.com/mingo/cfs-scheduler/
I tried this on 2.6.21.1, Good work!
I have a
26 May 2007 Cts tarihinde, S.Çağlar Onur şunları yazmıştı:
> 23 May 2007 Çar tarihinde, Ingo Molnar şunları yazmıştı:
> > As usual, any sort of feedback, bugreport, fix and suggestion is more
> > than welcome!
>
> I have another kaffeine [0.8.4]/xine-lib [1.1.6] problem with CFS for you
> :)
>
>
Hi Ingo;
23 May 2007 Çar tarihinde, Ingo Molnar şunları yazmıştı:
> As usual, any sort of feedback, bugreport, fix and suggestion is more
> than welcome!
I have another kaffeine [0.8.4]/xine-lib [1.1.6] problem with CFS for you :)
Under load (compiling any Qt app. or kernel with -j1 or -j2)
Hi Ingo;
23 May 2007 Çar tarihinde, Ingo Molnar şunları yazmıştı:
As usual, any sort of feedback, bugreport, fix and suggestion is more
than welcome!
I have another kaffeine [0.8.4]/xine-lib [1.1.6] problem with CFS for you :)
Under load (compiling any Qt app. or kernel with -j1 or -j2)
26 May 2007 Cts tarihinde, S.Çağlar Onur şunları yazmıştı:
23 May 2007 Çar tarihinde, Ingo Molnar şunları yazmıştı:
As usual, any sort of feedback, bugreport, fix and suggestion is more
than welcome!
I have another kaffeine [0.8.4]/xine-lib [1.1.6] problem with CFS for you
:)
Under load
Ingo Molnar wrote:
i'm pleased to announce release -v14 of the CFS scheduler patchset.
The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be
downloaded from the usual place:
http://people.redhat.com/mingo/cfs-scheduler/
I tried this on 2.6.21.1, Good work!
I have a
Ingo Molnar wrote:
> i found an accounting bug in this: it didnt sum up threads correctly.
> The patch below fixes this. The stime == 0 problem is still there
> though.
>
> Ingo
>
Thanks! I'll test the code on Monday. I do not understand the
sysctl_sched_smoothing functionality, so I do
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> btw., CFS does this change to fs/proc/array.c:
>
> @@ -410,6 +408,14 @@ static int do_task_stat(struct task_stru
> /* convert nsec -> ticks */
> start_time = nsec_to_clock_t(start_time);
>
> + /*
> + * Use CFS's precise
* Ingo Molnar [EMAIL PROTECTED] wrote:
btw., CFS does this change to fs/proc/array.c:
@@ -410,6 +408,14 @@ static int do_task_stat(struct task_stru
/* convert nsec - ticks */
start_time = nsec_to_clock_t(start_time);
+ /*
+ * Use CFS's precise accounting, if
Ingo Molnar wrote:
i found an accounting bug in this: it didnt sum up threads correctly.
The patch below fixes this. The stime == 0 problem is still there
though.
Ingo
Thanks! I'll test the code on Monday. I do not understand the
sysctl_sched_smoothing functionality, so I do not
Ingo Molnar wrote:
> it treats it as a per-cpu clock.
>
Excellent. I'd noticed it seems to work pretty well in a Xen guest with
lots of stolen time, but I haven't really evaluated it in detail.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> > nice! I've merged your patch and it built/booted fine so it should show
> > up in -v15. This should also play well with Andi's sched_clock()
> > enhancements in -mm, slated for .23.
> >
>
> BTW, does CFS treat
Ingo Molnar wrote:
> nice! I've merged your patch and it built/booted fine so it should show
> up in -v15. This should also play well with Andi's sched_clock()
> enhancements in -mm, slated for .23.
>
BTW, does CFS treat sched_clock as a per-cpu clock, or will it compare
time values of
Ingo Molnar wrote:
> btw., i think some more consolidation could be done in this area. We've
> now got the traditional /proc/PID/stat metrics, schedstats, taskstats
> and delay accounting and with CFS we've got /proc/sched_debug and
> /proc/PID/sched. There's a fair amount of overlap.
>
Yes.
* Balbir Singh <[EMAIL PROTECTED]> wrote:
> Hi, Ingo,
>
> I've implemented a patch on top of v14 for better accounting of
> sched_info statistics. Earlier, sched_info relied on jiffies for
> accounting and I've seen applications that show "0" cpu usage
> statistics (in delay accounting and
On Wed, May 23, 2007 at 02:06:16PM +0200, Ingo Molnar wrote:
>
> i'm pleased to announce release -v14 of the CFS scheduler patchset.
>
> The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be
> downloaded from the usual place:
>
>
On Wed, May 23, 2007 at 02:06:16PM +0200, Ingo Molnar wrote:
i'm pleased to announce release -v14 of the CFS scheduler patchset.
The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be
downloaded from the usual place:
http://people.redhat.com/mingo/cfs-scheduler/
* Balbir Singh [EMAIL PROTECTED] wrote:
Hi, Ingo,
I've implemented a patch on top of v14 for better accounting of
sched_info statistics. Earlier, sched_info relied on jiffies for
accounting and I've seen applications that show 0 cpu usage
statistics (in delay accounting and from /proc)
Ingo Molnar wrote:
btw., i think some more consolidation could be done in this area. We've
now got the traditional /proc/PID/stat metrics, schedstats, taskstats
and delay accounting and with CFS we've got /proc/sched_debug and
/proc/PID/sched. There's a fair amount of overlap.
Yes. true.
Ingo Molnar wrote:
nice! I've merged your patch and it built/booted fine so it should show
up in -v15. This should also play well with Andi's sched_clock()
enhancements in -mm, slated for .23.
BTW, does CFS treat sched_clock as a per-cpu clock, or will it compare
time values of
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
nice! I've merged your patch and it built/booted fine so it should show
up in -v15. This should also play well with Andi's sched_clock()
enhancements in -mm, slated for .23.
BTW, does CFS treat sched_clock as a
Ingo Molnar wrote:
it treats it as a per-cpu clock.
Excellent. I'd noticed it seems to work pretty well in a Xen guest with
lots of stolen time, but I haven't really evaluated it in detail.
J
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Le mercredi 23 mai 2007 à 21:57 +0200, Ingo Molnar a écrit :
> * Nicolas Mailhot <[EMAIL PROTECTED]> wrote:
>
> > Ingo Molnar elte.hu> writes:
> >
> > Hi Ingo
> >
> > > i'm pleased to announce release -v14 of the CFS scheduler patchset.
> > >
> > > The CFS patch against v2.6.22-rc2, v2.6.21.1
* Nicolas Mailhot <[EMAIL PROTECTED]> wrote:
> Ingo Molnar elte.hu> writes:
>
> Hi Ingo
>
> > i'm pleased to announce release -v14 of the CFS scheduler patchset.
> >
> > The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be
> > downloaded from the usual place:
> >
> >
Ingo Molnar elte.hu> writes:
Hi Ingo
> i'm pleased to announce release -v14 of the CFS scheduler patchset.
>
> The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be
> downloaded from the usual place:
>
> http://people.redhat.com/mingo/cfs-scheduler/
I get a forbidden
i'm pleased to announce release -v14 of the CFS scheduler patchset.
The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be
downloaded from the usual place:
http://people.redhat.com/mingo/cfs-scheduler/
In -v14 the biggest user-visible change is increased sleeper fairness
i'm pleased to announce release -v14 of the CFS scheduler patchset.
The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be
downloaded from the usual place:
http://people.redhat.com/mingo/cfs-scheduler/
In -v14 the biggest user-visible change is increased sleeper fairness
Ingo Molnar mingo at elte.hu writes:
Hi Ingo
i'm pleased to announce release -v14 of the CFS scheduler patchset.
The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be
downloaded from the usual place:
http://people.redhat.com/mingo/cfs-scheduler/
I get a forbidden
* Nicolas Mailhot [EMAIL PROTECTED] wrote:
Ingo Molnar mingo at elte.hu writes:
Hi Ingo
i'm pleased to announce release -v14 of the CFS scheduler patchset.
The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be
downloaded from the usual place:
Le mercredi 23 mai 2007 à 21:57 +0200, Ingo Molnar a écrit :
* Nicolas Mailhot [EMAIL PROTECTED] wrote:
Ingo Molnar mingo at elte.hu writes:
Hi Ingo
i'm pleased to announce release -v14 of the CFS scheduler patchset.
The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10
72 matches
Mail list logo
