On Feb 6, 2012, at 5:57 PM, Erik Erlandson wrote: > On Mon, 2012-02-06 at 15:46 -0700, Erik Erlandson wrote: > >> Given that we are considering some extensions to the concurrency limit >> features, it made me wonder if it would be a net win to dispense with >> partitionable/dynamic slots in favor of mem/disk pooling via some kind >> of per-machine concurrency limit accounting mechanism. > > > I've gotten one comment that concurrency limits per se aren't the right > place, as those are globally scoped across all pool nodes. > > A better question is: "what are the possible benefits versus drawbacks > of extracting mem/disk accounting out of slots and into some other kind > of per-node accounting mechanism" > > I don't see how you can avoid having claim logic know about these > resources. But it might conceivably be localized there. > > The accountant currently handles CL - it could conceivably be extended > to allow "scoped" CL, where one kind of scope could be machine names. > > Would potential simplifications be helpful enough to justify the implied > code and feature churn? > > Hi Erik, Isn't the "proper model" to have the pool of resources managed by the startd (as that is the agent that acts on behalf of the machine owner), not the negotiator? That "feels more right" to me, even if I articulate it poorly! I'm not sure how well this proposal would play with flocking. If there are multiple negotiators in the picture, who maintains the node's CL? Doesn't it have to be the startd? Brian
Attachment:
smime.p7s
Description: S/MIME cryptographic signature