From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Ogness Subject: Re: Realtime tasks and cgroups (cpu.shares) Date: Mon, 10 Jul 2017 15:39:14 +0200 Message-ID: <87fue4h0n1.fsf@linutronix.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-rt-users To: "Koehrer Mathias \(ETAS\/EHE1\)" Return-path: Received: from Galois.linutronix.de ([146.0.238.70]:39348 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754005AbdGJNjR (ORCPT ); Mon, 10 Jul 2017 09:39:17 -0400 In-Reply-To: (Koehrer Mathias's message of "Mon, 10 Jul 2017 12:57:05 +0000") Sender: linux-rt-users-owner@vger.kernel.org List-ID: Hi Mathias, On 2017-07-10, Koehrer Mathias (ETAS/EHE1) wrote: > is it possible to combine real time tasks and cgroups (in particular > cpu.shares)? The background of the question is the following: > If a real time task hangs by accident in an endless loop, it blocks > the complete access to the system. One idea could be to reserve a > small percentage of the CPU for non real time stuff to avoid these > kind of situations. For your particular situation, that is what the following proc-settings are for: /proc/sys/kernel/sched_rt_period_us /proc/sys/kernel/sched_rt_runtime_us However, be aware that these settings apply collectively to *all* realtime processes within a period. You need to be certain that a correctly running system is never in danger of hitting these deadlines. Otherwise you have crippled your realtime system. For cgroups, I assume you are referring to CONFIG_CFS_BANDWIDTH. I expect this would work as well, but personally have no experience using cgroups in this manner and am not certain that it has no adverse affects on realtime scheduling. John Ogness