<div dir="ltr">Tested this branch with 16,000 units and 32,000 units and it looks great. Much better than before.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 18, 2013 at 11:12 PM, David Timothy Strauss <span dir="ltr"><<a href="mailto:david@davidstrauss.net" target="_blank">david@davidstrauss.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm pretty confident in the accuracy of the controller mask<br>
aggregation, especially given the new unit test. Here are the main<br>
review questions.<br>
<br>
Is it okay to couple realizing the cgroups and applying the attributes<br>
the way the patch does? Before, we were often applying the attributes<br>
for all of a unit's siblings (read: other units in the same slice). I<br>
believe these should never change as long as the controller mask is<br>
the same as what's been realized already. Perhaps the old<br>
implementation was done to avoid re-computation of the target masks<br>
(which is no longer required).<br>
<br>
Is it okay to skip realization and attribute setting for<br>
inactive/failed units? If they do start, we will set the attributes at<br>
that time with this patch. If they're not running, giving them CPU and<br>
Block IO weights doesn't seem to have any worthwhile effect. Am I<br>
ignoring something about, say, CPU accounting (which I don't use<br>
myself)?<br>
<br>
Also, hat tip to my coworker Kyle Ibrahim for the original idea of not<br>
queuing inactive and failed units.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
systemd-devel mailing list<br>
<a href="mailto:systemd-devel@lists.freedesktop.org">systemd-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/systemd-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/systemd-devel</a><br>
</div></div></blockquote></div><br></div>