LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "J.C. Pizarro" <jcpiza@gmail.com>
To: "Rik van Riel" <riel@redhat.com>,
	"Mike Galbraith" <efault@gmx.de>,
	LKML <linux-kernel@vger.kernel.org>,
	"Linus Torvalds" <torvalds@linux-foundation.org>
Subject: Re: Please, put 64-bit counter per task and incr.by.one each ctxt switch.
Date: Sun, 24 Feb 2008 14:12:47 +0100	[thread overview]
Message-ID: <998d0e4a0802240512t859c5a1y3c30bd401530a43@mail.gmail.com> (raw)
In-Reply-To: <20080223232651.41dffa72@bree.surriel.com>

Good morning :)

On 2008/2/24, Rik van Riel <riel@redhat.com> wrote:
> OK, one last reply on the (overly optimistic?) assumption that you are not a troll.
>  > +++ linux-2.6_git-20080224/include/linux/sched.h        2008-02-24
>  > 04:50:18.000000000 +0100
>  > @@ -1007,6 +1007,12 @@
>  >         struct hlist_head preempt_notifiers;
>  >  #endif
>  >
>  > +       unsigned long long ctxt_switch_counts; /* 64-bit switches' count */
>  > +       /* ToDo:
>  > +        *  To implement a poller/clock for CPU-scheduler that only reads
>  > +        *   these counts of context switches of the runqueue's tasks.
>  > +        *  No problem if this poller/clock is not implemented. */
>
> So you're introducing a statistic, but have not yet written any code
>  that uses it?

It's statistic, yes, but it's a very important parameter for the CPU-scheduler.
The CPU-scheduler will know the number of context switches of each task
 before of to take a blind decision into infinitum!.

Statistically, there are tasks X that have higher context switches and
tasks Y that have lower context switches in the last sized interval with the
 historical formula "(alpha-1)*prev + alpha*current" 0 < alpha < 1.
(measure this value V as a velocity of number of ctxt-switches/second too)

      Put more weight to X than to Y for more interactivity that X want.
      (X will have more higher V and Y more lower V).
      With an exception for avoid the eternal humble, to do sin(x) behaviour
       after of a long period of humble (later to modify the weights).

The missing code has to be implemented between everybodies because
1. Users wann't lose interactivity in overloaded CPU.
2. There are much code of CPU-schedulers bad organizated that i wann't
     touch it.

>  > +       p->ctxt_switch_counts = 0ULL; /* task's 64-bit counter inited 0 */
>
> Because we can all read C, there is no need to tell people in comments
>  what the code does.  Comments are there to explain why the code does
>  things, if an explanation is needed.

OK.

>  > >  > I will explain your later why of it.
>  > >
>  > > ... and explain exactly why the kernel needs this extra code.
>  >
>  > One reason: for the objective of gain interactivity, it's an issue that
>  >  CFS fair scheduler lacks it.

> Your patch does not actually help interactivity, because all it does
>  is add an irq spinlock in a hot path (bad idea) and a counter which
>  nothing reads.

Then remove the lock/unlock of the task that i'd put it,
i'm not sure if it's secure because i didn't read all the control of the road.

On 2008/2/24, Mike Galbraith <efault@gmx.de> wrote:
>  > One reason: for the objective of gain interactivity, it's an issue that
>  >  CFS fair scheduler lacks it.
>
> A bug report would be a much better first step toward resolution of any
>  interactivity issues you're seeing than posts which do nothing but
>  suggest that there may be a problem.
>
>  First define the problem, _then_ fix it.

It's blind eternal problem in overloaded CPU scenario in the desktops.

  reply	other threads:[~2008-02-24 13:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-24  3:08 J.C. Pizarro
2008-02-24  3:17 ` Rik van Riel
2008-02-24  4:08   ` J.C. Pizarro
2008-02-24  4:26     ` Rik van Riel
2008-02-24 13:12       ` J.C. Pizarro [this message]
2008-02-24 17:53         ` Mike Galbraith
2008-02-25 20:34         ` Andrew Morton
2008-02-26 13:20           ` J.C. Pizarro
2008-02-26 13:41             ` Alexey Dobriyan
2008-02-24  5:08     ` Mike Galbraith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=998d0e4a0802240512t859c5a1y3c30bd401530a43@mail.gmail.com \
    --to=jcpiza@gmail.com \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --subject='Re: Please, put 64-bit counter per task and incr.by.one each ctxt switch.' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).