From: Ingo Molnar <mingo@elte.hu>
To: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>,
Con Kolivas <kernel@kolivas.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Mike Galbraith <efault@gmx.de>
Subject: Re: [PATCH -mm] scheduler: fix the return of the first time_slice
Date: Mon, 16 Apr 2007 13:54:41 +0200 [thread overview]
Message-ID: <20070416115441.GA26177@elte.hu> (raw)
In-Reply-To: <20070416114701.GB84@tv-sign.ru>
* Oleg Nesterov <oleg@tv-sign.ru> wrote:
> > > * The remainder of the first timeslice might be recovered by
> > > * the parent if the child exits early enough.
> > > */
> > > - p->first_time_slice = 1;
> > > + p->time_slice_reaper = current;
> > > p->timestamp = sched_clock();
> > > local_irq_enable();
> >
> > I am afraid this doesn't work for CLONE_THREAD. Suppose that some
> > sub-thread (not main thread) T1 creates another sub-thread, T2.
> In case I was not clear...
> To make this correct, we should iterate over all thread-group, but
> this can slow down exit() when we have a lot of threads.
>
> I guess we need Ingo's opinion on that.
right now my first cautious estimation seems to be that we might be able
to get rid of this whole child/parent timeslice sharing complexity and
do all the scheduling setup without affecting the parent - hence
avoiding all the reaper problems as well. People reported interactivity
improvements with this removed from CFS. (It all still needs a ton of
validation to make sure, but the trend seems to be this.)
(the only valid component of that complexity is 'child runs first' - but
it's not really related to the timesplice splitting thing just
intermixed with it.)
Ingo
next prev parent reply other threads:[~2007-04-16 11:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-07 7:31 [BUG] scheduler: first timeslice of the exiting thread Satoru Takeuchi
2007-04-07 7:45 ` Satoru Takeuchi
2007-04-09 6:09 ` Andrew Morton
2007-04-09 6:50 ` Mike Galbraith
2007-04-10 7:18 ` Satoru Takeuchi
2007-04-13 15:31 ` Con Kolivas
2007-04-16 2:16 ` [PATCH] scheduler: fix the return of the first time_slice Satoru Takeuchi
2007-04-16 4:36 ` [PATCH -mm] " Satoru Takeuchi
2007-04-16 10:45 ` Oleg Nesterov
2007-04-16 11:47 ` Oleg Nesterov
2007-04-16 11:54 ` Ingo Molnar [this message]
2007-04-16 11:58 ` Satoru Takeuchi
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=20070416115441.GA26177@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=efault@gmx.de \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@tv-sign.ru \
--cc=takeuchi_satoru@jp.fujitsu.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.