linux-kernel - Re: report a bug about sched

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: <454c71700907240724u76b970e5y5af0fc114cc92f83@mail.gmail.com>
Date:	Fri, 24 Jul 2009 22:24:02 +0800
From:	sen wang <wangsen.linux@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	mingo@...e.hu, akpm@...ux-foundation.org, kernel@...ivas.org,
	npiggin@...e.de, arjan@...radead.org,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	linux-kernel@...r.kernel.org
Subject: Re: report a bug about sched_rt

2009/7/24 Peter Zijlstra <peterz@...radead.org>:
> On Fri, 2009-07-24 at 21:44 +0800, sen wang wrote:
>> 2009/7/24 Peter Zijlstra <peterz@...radead.org>:
>> > On Fri, 2009-07-24 at 21:26 +0800, sen wang wrote:
>> >> don't tell me what theory. don't be so doctrinairism! OK?
>> >> If cpu is free and there is a running state task,how can you scdedule
>> >> idle task up?
>> >> I tell you again:we are not talking about a bandwidth of 100% for RT!
>> >> Bug lies in the bandwidth of (100- X)%.(X<100)
>> >> even in the time of 100-X,if there is a rt task, you should not idle()
>> >> the system.
>> >
>> > *sigh*
>> >
>> > Yes we should. I appreciate that you might assume otherwise, but you're
>> > wrong. Suppose you have two competing bandwidth groups, which one will
>> > run over, to what purpose?
>> >
>> > Also, your next top post will go to /dev/null.
>> >
>>
>>
>> OK !  maybe you has not understand what I said.
>> It not two competing bandwidth groups. there is a  active group and
>> another is empty?
>> How you do?
>
> 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;
...
}

>> Why not try it by your hand: empty the fair task, run a rt task,enable
>> the  bandwidth and
>> see what will happen!
>
> Oh, I know, I wrote the code.
>
>> In many embedded system,idle task will lead to shutdown something, but
>> the rt task will
>> assume: when it run, idle will not happen!
>
> 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?



>
> 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?
--
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/