First way

The idea is to allow the cpuset field in the database to store the id or many threads, e.g. 1,8 for thread 1 and thread 8. As a result the cpuset field in OAR database must be converted from Int to Varchar. This implies a database schema upgrade.

We have to check that code that changes or accesses the cpuset field will not break.

Also the job resource manager will have to make use of the cpuset field correctly.

This is implemented in versions >= 2.5.4.

Second way

Generally when a job wants to use Hyperthreading CPU feature it means that it can/must run on a whole computing node.

So it could be useful to have a job type “hypertheading”. Then when this kind of job reserves whole nodes (all the CPUs and cores) then the job_resource_manager turns on the hyperthreaded cores automatically. At the end of the jobs the hyperthreaded cores are removed.

Is someone interested by this feature???

moved to

wiki/todos/handle_hyperthreading_setup_in_jobs.txt · Last modified: 2016/03/02 14:38 by neyron
Recent changes RSS feed GNU Free Documentation License 1.3 Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki