linux-kernel - Re: [BUG] scheduler: first timeslice of the exiting thread

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200704140131.12500.kernel@kolivas.org>
Date:	Sat, 14 Apr 2007 01:31:12 +1000
From:	Con Kolivas <kernel@...ivas.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Satoru Takeuchi <takeuchi_satoru@...fujitsu.com>,
	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Mike Galbraith <efault@....de>
Subject: Re: [BUG] scheduler: first timeslice of the exiting thread

On Monday 09 April 2007 16:09, Andrew Morton wrote:
> On Sat, 07 Apr 2007 16:31:39 +0900 Satoru Takeuchi 
<takeuchi_satoru@...fujitsu.com> wrote:
> > When I was examining the following program ...
> >
> >   1. There are a large amount of small jobs takes several msecs,
> >      and the number of job increases constantly.
> >   2. The process creates a thread or a process per job (I examined both
> >      the thread model and the process model).
> >   3. Each child process/thread does the assigned job and exit
> > immediately.
> >
> > ... I found that the thread model's latency is longer than proess
> > model's one against my expectation. It's because of the current
> > sched_fork()/sched_exit() implementation as follows:
> >
> >   a) On sched_fork, the creator share its timeslice with new process.
> >   b) On sched_exit, if the exiting process didn't exhaust its first
> >      timeslice yet, it gives its timeslice to the parent.
> >
> > It has no problem on the process model since the creator is the parent.
> > However, on the thread model, the creator is not the parent, it is same
> > as the creator's parent. Hence, on this kind of program, the creator
> > can't retrieve shared timeslice and exausts its timeslice at a rate of
> > knots. In addition, somehow, the parent (typically shell?) gets extra
> > timeslice.
> >
> > I believe it's a bug and the exiting process should give its timeslice
> > to the creator. Now I have some patch plan to fix this problem as follow:
> >
> >  a) Add the field for the creator to task_struct. It needs extra memory.
> >  b) Doesn't add extra field and have thread's parent the creater, which
> > is same as process creation. However it has many side effects, for
> > example, we also need to change sys_getppid() implementation.
> >
> > What do you think? Any comments are welcome.
>
> This comes at an awkward time, because we might well merge the
> staircase/deadline work into 2.6.22, and I think it rewrites the part of
> the scheduler which is causing the problems you're observing.
>
> Has anyone verified that SD fixes this problem and the one at
> http://lkml.org/lkml/2007/4/7/21 ?

No, SD does nothing different in this regard. There is no notion of who made 
the thread and who the remaining timeslice should go to. As you say, some 
decision on sched_exit should probably be used to decide where to send it. In 
the absence of yet more fields in task_struct, the easiest thing to do would 
be to check if the the thread id is equal to the pid and if not, send it to 
the pid (or any parent of that if it no longer exists). Whether it's worth 
adding yet another field to task_struct to track this or not I do not have 
enough information to make an informed choice in this regard. Either way I'm 
low on patch-creation cycles so please feel free to provide your solution.

-- 
-ck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/