Bug 6999 - Integrate multi-core support and add authorization handling for it
: Integrate multi-core support and add authorization handling for it
: Nimbus
Workspace service
: 2.3
: PC Linux
: P3 normal
: 3.0
Assigned To:
: 7013
  Show dependency treegraph
Reported: 2010-04-14 17:17 by
Modified: 2010-06-19 23:47 (History)



You need to log in before you can comment on or make changes to this bug.

Description From 2010-04-14 17:17:13
Patrick Armstrong has contributed multi-core support.  It looks good, I think
for it to really work we should design more general scheduling and
authorization hooks.  

These will prevent oversubscriptions (scheduling) and track people's multi-core
usage as an extra docket against their allocations (used in any future
authorization decisions).

We will make sure a developer codes those parts before the next release after
2.4 which is either 2.5 or 3.0.

Thanks Patrick.
------- Comment #1 From 2010-05-19 10:09:24 -------
There is some confusion about this integration of multi-core into the current
accounting mechanisms.  I think now it seems likely Nimbus will move to a
'credit' based system where minutes aren't even the currency.  The presence of
multiple cores would make your allocation 'more expensive' in terms of credits.
 But this is summer work and I am trying to think about how we should approach
this bug.  Any comments?
------- Comment #2 From 2010-05-19 12:21:58 -------
Well, at this point, is a user charged more minutes if they request more
memory? If not, then should they be charged for more CPU? Then in the future,
when credits are implemented, we can create some function where Memory, CPU,
etc are the input and nimbucks are the output.
------- Comment #3 From 2010-05-19 12:27:13 -------
Yeah, right now they are not charged by memory either.  The algorithm for
coming up with the "Nimbucks" that would be spent is currently what's under

Maybe we include multi-cpu then withOUT the accounting.  Maybe just an
enhancement to group-authz that says maxcores?
------- Comment #4 From 2010-05-19 12:50:24 -------
Yep, that would be fine by me. I wouldn't even mind implementing it. I should
have time this week to look at it.
------- Comment #5 From 2010-05-19 13:27:47 -------
That would be great, it should not be very difficult.  And I think if the new
setting is not present in the policy file, it could imply not to worry about
that particular part of the request.  Thanks Patrick.
------- Comment #6 From 2010-05-27 12:48:24 -------
Okay, I have a proposed patch for this bug in github right now.

I wasn't too sure that getZeroOrPositiveLongAllowNull method was the best way
to go about the problem (or that it was the best name for that method, but I
couldn't think of anything cleverer. I'm also not sure about whether I need to
include maxCPUs in all of the groupxx.properties examples, or whether 2 is a
good example value.
------- Comment #7 From 2010-06-07 11:58:21 -------
Patrick, thankyou very much, sorry it's taken me so long to get to this.  I've
visually reviewd and it looks good to me.  I will merge to master and test

------- Comment #8 From 2010-06-07 12:00:15 -------
No worries, if you notice anything awry, let me know, and I can make some
------- Comment #9 From 2010-06-08 16:45:42 -------
I will account for the differences between your original work and the
differences introduced by this patch to the scheduler:


------- Comment #10 From 2010-06-19 23:16:06 -------
Thankyou Patrick!!  Basic exercising of it in the context of this pre-Nimbus
2.4 5 master is done, it will go under more tests when Bug 7062 is completed.

Merged into master for Nimbus 2.5:


NOTE this adds an optional field to the WSRF protocol.  This is backwards
compatible: if it is missing, the default is chosen as it always has been
(default is configured in "etc/workspace-control/main.conf" on VMMs).
------- Comment #11 From 2010-06-19 23:47:40 -------
The schedule thing mentioned in Comment #9 is not relevant now actually. The
scheduler will not be taking core into account as of the merge mentioned in
Comment #10