linux-kernel - Re: [PATCH] kthread: always create the kernel threads with normal priority

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]

Date:	Mon, 07 Jan 2008 18:47:59 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Michal Schmidt <mschmidt@...hat.com>,
	linux-kernel@...r.kernel.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Jon Masters <jcm@...hat.com>,
	Satoru Takeuchi <takeuchi_satoru@...fujitsu.com>
Subject: Re: [PATCH] kthread: always create the kernel threads with normal
	priority

On Mon, 2008-01-07 at 09:29 -0800, Andrew Morton wrote:
> On Mon, 7 Jan 2008 12:09:04 +0100 Ingo Molnar <mingo@...e.hu> wrote:
> 
> > 
> > > > This causes a practical problem. When a runaway real-time task is 
> > > > eating 100% CPU and we attempt to put the CPU offline, sometimes we 
> > > > block while waiting for the creation of the highest-priority 
> > > > "kstopmachine" thread.
> > 
> > sched-devel.git has new mechanisms against runaway RT tasks. There's a 
> > new RLIMIT_RTTIME rlimit - if an RT task exceeds that rlimit then it is 
> > sent SIGXCPU.
> 
> Is that "total RT CPU time" or "elapsed time since last schedule()"?
> 
> If the former, it is not useful for this problem.
> 
> > there's also a new group scheduling extension that is driven via a 
> > sysctl:
> > 
> >   /proc/sys/kernel/sched_rt_ratio
> > 
> > this way if a user has a runaway RT task, other users (and root) will 
> > still have some CPU time left. (in Peter's latest patchset that is 
> > replaced via rt_runtime_ns - but this is a detail)
> 
> Doesn't this make the RT task non-RT?  Would need to understand more
> details to tell.

Its an artifact of rt group scheduling. Each group will have to specify
a period and runtime limit therein (and the normalized sum thereof must
not exceed the total time available - otherwise the set is not
schedulable).

So say we have two groups A and B. A has a period of 2 seconds and a
runtime limit of 1, that gives him an avg of 50% cpu time. If B then has
a period of 1 second with a runtime limit of .25s (avg 25%) the total
time required to schedule the realtime groups would be 75% on average.

Without group scheduling everything is considered one group but we still
have the period and runtime limits.

So as long as the realtime cpu usage fits within the given limits it
acts as before. Once it exceeds its limit it will be capped hard - which
is ok, since it exceeded its hard limit, and realtime applications are
supposed to be deterministic and thus be able to tell how much time
they'd require. [ If only this model were true, but its a model
frequently used and quite accepted ]

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)