DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=MHWHV89KiZktBLWW8Nj6q//HQ3q29R2YP9YYeBOxrm3W0Ga+RkcdpSroLRWDb+ZZsq
         BfVKqxweW2q2tFcbk4mgN71kSoZAV1mvXU4Wm/6C2uN+bfKzDa9/oqDOvnSqAQ2Aa7dl
         N5hy952q1sPE6NCNTln85jYsBGMpy90Z1Nebs=
MIME-Version: 1.0
In-Reply-To: <1248446910.6987.111.camel@twins>
References: <454c71700907240357l61f5c4fajaca73db0fba7db8@mail.gmail.com>
	 <1248437670.6987.26.camel@twins>
	 <454c71700907240604h4673f117j8ed58b9f2ee54798@mail.gmail.com>
	 <1248441290.6987.52.camel@twins>
	 <454c71700907240626w127fd890ufa91ef90cbcaaa@mail.gmail.com>
	 <1248442415.6987.56.camel@twins>
	 <454c71700907240644h7469e2a5sfcb57f202a2e184d@mail.gmail.com>
	 <1248443656.6987.61.camel@twins>
	 <454c71700907240724u76b970e5y5af0fc114cc92f83@mail.gmail.com>
	 <1248446910.6987.111.camel@twins>
Date: Fri, 24 Jul 2009 23:02:49 +0800
Message-ID: <454c71700907240802m19a40b83we3740aa40c3b4ae5@mail.gmail.com>
Subject: Re: report a bug about sched_rt
From: sen wang <wangsen.linux@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: mingo@elte.hu, akpm@linux-foundation.org, kernel@kolivas.org,
       npiggin@suse.de, arjan@infradead.org,
       linux-arm-kernel@lists.arm.linux.org.uk, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3268
Lines: 78

2009/7/24 Peter Zijlstra <peterz@infradead.org>:
> On Fri, 2009-07-24 at 22:24 +0800, sen wang wrote:
>
>> > No, but the 1 group is the trivial case of many groups. Changing the
>> > semantics for the trivial case is inconsistent at best, and confusing at
>> > worst.
>
>> yes! 1 group is the trivial case ,but you can't say it is useless. and
>> in some system
>> it is important!
>> I have read across the schedule codes and tried this way,it work:
>> static struct task_struct *pick_next_task_rt(struct rq *rq)
>> { ...
>>        if (rt_rq_throttled(rt_rq)&& rq->cfs.nr_running)
>>                return NULL;
>> ....
>> }
>
> That might work in the current implementation, but like I already
> explained, its not consistent with the multi-group case. Also, people
> are working on making it a proper EDF scheduled CBS, it won't
> generalize.
>
>> > How is it my problem when you design your system wrong?
>>
>> my system is good. but there is no rules what the idle task will do,so.
>> people always write codes in idle task with the assume: no any running
>> task in the system.
>> and people also always write codes in rt task with the assume: if I am
>> in running state
>> ,system will not idle.
>>
>> so what i said above is some like theory,but I don't like the word “theory".
>> I call it people's common sense.
>>
>> but the behavior of the  throttled RT group is changed from people's
>> common sense,so don't say people's common sense is wrong. OK?
>
> There are plenty of examples where common sense utterly fails, the one
> that comes to mind is Probability Theory.
>
>> > If you want your 1 RT group to not get throttled, disable the throttle,
>> > or adjust it to fit the parameters of your workload. If you don't want
>> > idle to have latency impact on your RT tasks, fix your idle behaviour.
>> >
>>
>> 1 RT is important to me. But I also have fair task, so  throttled is
>> also important to me.
>> and don't say : idle have latency impact on RT tasks. It is too
>> ludicrous Why we make   intended latency impact by ourselves,by wrong
>> idle task?
>
> Yes, configurable idle tasks are nothing new. If you care about wakeup
> latency then idle=poll is preferred (it sucks for power saving, but such
> is life).
>
> On your embedded board you seem to have a particularly aggressive idle
> function wrt power savings, which would result in rather large wake from
> idle latencies, regardless of the bandwidth throttle, so what is the
> problem?
>
don't guess what i do in my idle? my idle is perfect!
and don't think only you understand the scheduling and waht you
consider is right.
linux is a free world.

> If you're using the bandwidth throttle to control your RT tasks so as
> not to starve your SCHED_OTHER tasks, then I will call your system ill
> designed.
>
 the bandwidth throttle to control RT tasks is useful.  of course , I know how
not to prevent SCHED_OTHER tasks from being starved. we just discuss how to
deal with the 100-X time. and very unfortunatly,you are wrong.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/