[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1301315307.4859.13.camel@twins>
Date: Mon, 28 Mar 2011 14:28:27 +0200
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Minchan Kim <minchan.kim@...il.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
David Rientjes <rientjes@...gle.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Rik van Riel <riel@...hat.com>,
Oleg Nesterov <oleg@...hat.com>, linux-mm <linux-mm@...ck.org>,
Andrey Vagin <avagin@...nvz.org>,
Hugh Dickins <hughd@...gle.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
"Luis Claudio R. Goncalves" <lclaudio@...g.org>
Subject: Re: [PATCH 2/5] Revert "oom: give the dying task a higher priority"
On Mon, 2011-03-28 at 21:21 +0900, Minchan Kim wrote:
> Hi Peter,
>
> On Mon, Mar 28, 2011 at 11:51:36AM +0200, Peter Zijlstra wrote:
> > On Fri, 2011-03-25 at 00:27 +0900, Minchan Kim wrote:
> > >
> > > At that time, I thought that routine is meaningless in non-RT scheduler.
> > > So I Cced Peter but don't get the answer.
> > > I just want to confirm it.
> >
> > Probably lost somewhere in the mess that is my inbox :/, what is the
> > full question?
>
> The question is we had a routine which change rt.time_slice with HZ to
> accelarate task exit. But when we applied 93b43fa5508, we found it isn't effective
> any more about normal task. So we removed it. Is it right?
rt.time_slice is only relevant to SCHED_RR, since you seem to use
SCHED_FIFO (which runs for as long as the task is runnable), its
completely irrelevant.
> And Kosaki is about to revert 93b43fa5508 to find out the problem of this thread
> and Luis said he has a another solution to replace 93b43fa5508.
> If rt.time_slice handleing is effective, we should restore it until Luis's patch
> will be merged.
Right, so only SCHED_RR is affected by time_slice, it will be
decremented on tick (so anything that avoids ticks will also avoid the
decrement) and once it reaches 0 the task will be queued at the tail of
its static priority and reset the slice. If there is no other task on
that same priority we'll again schedule that task.
In short, don't use SCHED_RR and don't worry about time_slice.
--
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/
Powered by blists - more mailing lists