Re: [Condor-users] Feature Request: ability to set processor affinityfor a slot

["Matt Hope" <Matt.Hope@xxxxxxxxxxxxxxx>]

Just to say that we do this as well but we just do it 'within' the job
itself by parsing the command line arguments and popping $SlotId in
there...

It is likely as core numbers increase but other resources do not that we
might want to have a general per slot affinity mask configured within
condor (so some slots are given more than others and NUMA boxes can
better split things up based on memory locality).

Matt

-----Original Message-----
From: condor-users-bounces@xxxxxxxxxxx
[mailto:condor-users-bounces@xxxxxxxxxxx] On Behalf Of Ian Chesal
Posted At: 08 January 2009 22:24
Posted To: announce-condor
Conversation: Feature Request: ability to set processor affinity for a
slot
Subject: [Condor-users] Feature Request: ability to set processor
affinityfor a slot


Ahh the world of threads -- what a world it is! Full of lot of nastiness
and complicated debugging issues.

Which leads me to my first feature request of this glorious new year:
2009.

I'd like to be able to tell Condor, preferrably on a per-job basis but
even on a per-slot basis this would be great, to spawn the job command
with a processor affinity bit mask so the command and any child threads
from it are locked to a particular processor on a machine (or a
particular set of processors).

Right now I'm handling this by wrapping my *real* command in a higher
level command that Condor calls and the wrapper calls my real command
with a custom executable I've written that sets the processor affinity
bit mask for the real command.

Seems like a not un-natural feature to have the in the startd, nes pas?

The ideal implementation would let me set a different bit mask for each
slot. So slot 1 could lock threads to processor 0, slot 2 to process 1,
etc. I can't think how it could be done on a per-job basis because I'm
going to want to lock a job down based on the slot id.

Happy New Year Condor Team!

- Ian

Confidentiality Notice.
This message may contain information that is confidential or otherwise
protected from disclosure. If you are not the intended recipient, you
are hereby notified that any use, disclosure, dissemination,
distribution,  or copying  of this message, or any attachments, is
strictly prohibited.  If you have received this message in error, please
advise the sender by reply e-mail, and delete the message and any
attachments.  Thank you.

_______________________________________________
Condor-users mailing list
To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx with
a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/condor-users

The archives can be found at: 
https://lists.cs.wisc.edu/archive/condor-users/

----
Gloucester Research Limited believes the information provided herein is reliable. While every care has been taken to ensure accuracy, the information is furnished to the recipients with no warranty as to the completeness and accuracy of its contents and on condition that any errors or omissions shall not be made the basis for any claim, demand or cause for action.
The information in this email is intended only for the named recipient.  If you are not the intended recipient please notify us immediately and do not copy, distribute or take action based on this e-mail.
All messages sent to and from this email address will be logged by Gloucester Research Ltd and are subject to archival storage, monitoring, review and disclosure.
Gloucester Research Limited, 5th Floor, Whittington House, 19-30 Alfred Place, London WC1E 7EA.
Gloucester Research Limited is a company registered in England and Wales with company number 04267560.
----