Comment # 19 on bug 1107617 from Martin Wilck

(In reply to Franck Bui from comment #17)
> (In reply to Martin Wilck from comment #16)

> Well if you're 100% confident that 2 is the best choice for SLE then fine to
> use this value.

My recommendation is still 2, with an increased constant minimum (K=32 in
comment 0). This would provide more workers in the laptop case, while avoiding
sky-rocketing numbers for big systems.

"100% confidence" is hard to assert, but I have a pretty high confidence level
in this.

(In reply to Franck Bui from comment #18)
> Well I wouldn't be as categorical because as you know it's pretty hard to
> find a good value that would please all setups. And 8 doesn't seem too bad
> for desktops.

Yes, I was exaggerating. He's still far below our value of 64. Doing the math
like in comment 0 (again: first column "cpu limit", 2nd column "amount of RAM
in GiB above which the CPU limit counts):

       | new upstream | old upstream  |               |
#CPUs  | C=8, K = 10  | C = 2, K = 10 | C = 8, K = 32 | C = 2, K = 32
-------------------------------------------------------------------------
   1   |   16      2  |  10     1.3   |   32       4  |    32      4
   2   |   24      3  |  12     1.5   |   32       4  |    32      4
   4   |   40      5  |  16       2   |   40       4  |    32      4
   8   |   72      9  |  24       3   |   72       4  |    32      4
  16   |  136     17  |  40       5   |  136       5  |    40      5
1024   | 8200   1049  |2056     263   | 8200    1049  |  2056    263

Systems with ~1000 CPUs are not rare these days. Looking at the last row, you
can see that the worker numbers get quite large with C=8. IMHO much more than
2000 workers can't be healthy on any system, no matter now big.

I think that the main mistake is the belief that udev is CPU-intensive, and
thus the number of allowed workers has to increase with the number of CPUs. It
is not, at probably has never been. It's I/O bound, and sometimes, bound by 
resources such as locks. This is an argument to scale only weakly with the
number of CPUs, and my rationale to suggest a scale factor C = 2 with a higher
minimum number (K = 32 or 40). Combined with an absolute maximum of 2048, this
would be the formula I find optimal for most scenarios.

(In reply to Franck Bui from comment #18)
> That said I'm wondering if we shouldn't make the default value configurable
> at compile time so at least servers would use a lower value (let's say 2)

I doubt that our PMs would like to ship different udev binaries for SLES and
SLED. But in general, yes, I'd find it useful to make the parameters of the
formula configurable.