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-next>] [day] [month] [year] [list]
Date:	Sat, 5 Sep 2009 17:47:39 -0700
From:	Anirban Sinha <ani@...rban.org>
To:	linux-kernel@...r.kernel.org, fchecconi@...il.com,
	Ingo Molnar <mingo@...e.hu>, a.p.zijlstra@...llo.nl
Cc:	Anirban Sinha <ASinha@...gmasystems.com>,
	Anirban Sinha <ani@...rban.org>
Subject: Re: question on sched-rt group allocation cap: sched_rt_runtime_us



 > You say you pin the threads to a single core: how many cores does  
your
 > system have?

The results I sent you were on a dual core blade.


 > If this is the case, this behavior is the expected one, the scheduler
 > tries to reduce the number of migrations, concentrating the bandwidth
 > of rt tasks on a single core.  With your workload it doesn't work  
well
 > because runtime migration has freed the other core(s) from rt  
bandwidth,
 > so these cores are available to SCHED_OTHER ones, but your  
SCHED_OTHER
 > thread is pinned and cannot make use of them.

But, I ran the same routine on a quadcore blade and the results this  
time were:

rt_runtime/rt_period  % of iterations of reg thrd against rt thrd

0.20                  46%
0.25                  18%
0.26                  7%
0.3                   0%
0.4                   0%
(rest of the cases)   0%

So if the scheduler is concentrating all rt bandwidth to one core, it  
should be effectively 0.2 * 4 = 0.8 for this core. Hence,  we should  
see the percentage closer to 20% but it seems that it's more than  
double. At ~0.25, the regular thread should make no progress, but it  
seems it does make a little progress.
--
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