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] [day] [month] [year] [list]
Message-Id: <71F08B76-1EC2-4868-BFF5-944B3F83A9F1@anirban.org>
Date:	Sun, 6 Sep 2009 17:41:47 -0700
From:	Anirban Sinha <ani@...rban.org>
To:	Mike Galbraith <efault@....de>
Cc:	Anirban Sinha <ASinha@...gmasystems.com>,
	Lucas De Marchi <lucas.de.marchi@...il.com>,
	linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: question on sched-rt group allocation cap: sched_rt_runtime_us


On 2009-09-06, at 8:09 AM, Mike Galbraith wrote:

> On Sun, 2009-09-06 at 07:53 -0700, Anirban Sinha wrote:
>>
>>
>>
>>> Seems kjournald can end up depending on kblockd/3, which ain't
>>> going anywhere with that 100% RT hog in the way,
>>
>> I think in the past AKPM's response to this has been "just don't do
>> it", i.e, don't hog the CPU with an RT thread.
>
> Oh yeah, sure.  Best to run RT oinkers on isolated cpus.

Correct. Unfortunately at some places, the application coders do  
stupid things and then the onus falls on the kernel guys to make  
things 'just work'.

I would not have any problems if such a cap mechanism did not exist at  
all. However, since we do have such a tuning knob. I would say that  
let's make it do what it is supposed to do. In the documentation it  
says  "0.05s to be used by SCHED_OTHER". Unfortunately, it never hints  
that if your thread is tied to the RT core, you are screwed. The  
bandwidth accumulation logic would virtually kill all the remaining  
SCHED_OTHER threads, much before that 95% cap is reached. Somewhere it  
doesn't quite seem right. At the very very least, can we have this  
clearly written in sched-rt-group.txt?

Cheers,

Ani

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ