Closed parsonsmatt closed 1 year ago
IMO it seems pretty dodgy that poolMaxResources
is actually a lower bound on how many resources can be created, and that it can create potentially many more.
I'm going to submit a patch that accepts a poolNumStripes
config parameter. The smallest change is to use that instead of getNumCapabilities
when it is present. A more invasive change is to ensure that only enough Stripe
s are created such that poolMaxResources
is never exceeded (ie requesting poolMaxResources = 4
and poolNumStripes = 5
only actually creates 4 stripes, so that we definitely do not exceed the poolMaxResources
).
Then we get 20 stripes, each with 1 resource each.
Out of curiosity, why are you running 20 capabilities? Do you have a machine with 20 physical cores?
Yes, my laptop has 20 cores. getNumCapabilities >>= print
shows 20
.
I see. How many of these are physical? Asking since according to my experimentations running more capabilities than physical cores (and if you run with +RTS -N
, getNumCapabilities
will give you the number of logical cores) reduces performance, most likely due to GC overhead (and perhaps redundant context switches).
Huh apparently I have 14 physical cores, 8 "effiicency" and 6 "performance." Wild! And I guess hyperthreading gets me up to 20.
Version 2 would accept an
Int
parameter for how many stripes to create. Version 3 usesgetNumCapabilites
unconditionally.We're running into problems upgrading, and I think this may be related. Previously, with a
createPool _ _ 1 3600 4
call, you'd have1
stripe and4
resources per stripe. But now you will have 4 stripes, with 1 resource per stripe. Locally, I'm seeing errors about "refusing to create resource 12", when we have acreatePool _ _ 1 3600 4
call.getNumCapabilities
on my machine returns20
, so when we calculate the max resources, we get4
(4 resources, 1 stripe). Then we get 20 stripes, each with 1 resource each.I'd suggest adding a field for configuring stripe count on
PoolConfig
- that should alleviate this issue.