Re: [Mauiusers] Question about Maui data structures
Hi Michel, Thanks for the info... so, basically, compatibility and homogeneity. On Thu, 2015-12-10 at 16:05 -0500, Michel Béland wrote: > [...] If I were to change our few clusters from Torque/Maui to SLURM, > this would disturb all the users, not only the staff. Lots of users > run on several cluster at different sites. Putting my user hat on, I was actually very happy about the switch, because in my opinion, sbatch directives and environment variables are much more convenient than qsub equivalents, and it was able to handle dozens of thousands of jobs with ease, which didn't work all that smoothly with Torque / Maui. Of course, I might not be your typical user... :-) > Anyway, the last time I looked at SLURM, it seemed to me that its > scheduler had many options missing compared to Maui. Maybe it is > better now. I have to admit that I've only used both in a very basic configuration: basically, all I needed was sane backfill scheduling and the corresponding SLURM plugin worked just fine for this purpose. -- Sincerely yours, Yury V. Zaytsev ___ mauiusers mailing list mauiusers@supercluster.org http://www.supercluster.org/mailman/listinfo/mauiusers
Re: [Mauiusers] Question about Maui data structures
Hi Yuri, > I'm genuinely curious as to why one would actually want to fix Maui or > even write a Maui-compatible scheduler from scratch this day and year? > > I've been using Torque & Maui for quite some time, but eventually got > tired of patching and finally completely discouraged once I've realized > that it's been abandoned for practical purposes. > > At the same time, I've discovered the awesomeness of SLURM and I see no > reason to look back. Besides, there are other free batch & scheduling > systems, such as the already mentioned Son of Grid Engine, so... > > Why Maui? I still get shivers thinking of the last time I had a look at > the source code... We might change to SLURM at some point, especially if the four national systems to be installed next year (here in Canada) go this route, but for the time being we want to maintain some compatibility between installed system. All the systems that we provide in my province use Torque with either Moab or Maui. I take care of Torque and Maui here on campus. If I were to change our few clusters from Torque/Maui to SLURM, this would disturb all the users, not only the staff. Lots of users run on several cluster at different sites. Anyway, the last time I looked at SLURM, it seemed to me that its scheduler had many options missing compared to Maui. Maybe it is better now. -- Michel Béland, analyste en calcul scientifique michel.bel...@calculquebec.ca bureau S-250, pavillon Roger-Gaudry (principal), Université de Montréal téléphone : 514 343-6111 poste 3892 télécopieur : 514 343-2155 Calcul Québec (www.calculquebec.ca) Calcul Canada (calculcanada.ca) ___ mauiusers mailing list mauiusers@supercluster.org http://www.supercluster.org/mailman/listinfo/mauiusers
Re: [Mauiusers] Question about Maui data structures
On Thu, 2015-12-10 at 11:02 -0500, Michel Béland wrote: > > I totally agree. The question remains whether we can accomplish this > by modifying Maui or by rewriting it from scratch... I'm genuinely curious as to why one would actually want to fix Maui or even write a Maui-compatible scheduler from scratch this day and year? I've been using Torque & Maui for quite some time, but eventually got tired of patching and finally completely discouraged once I've realized that it's been abandoned for practical purposes. At the same time, I've discovered the awesomeness of SLURM and I see no reason to look back. Besides, there are other free batch & scheduling systems, such as the already mentioned Son of Grid Engine, so... Why Maui? I still get shivers thinking of the last time I had a look at the source code... -- Sincerely yours, Yury V. Zaytsev ___ mauiusers mailing list mauiusers@supercluster.org http://www.supercluster.org/mailman/listinfo/mauiusers
Re: [Mauiusers] Question about Maui data structures
Hi Randall, > I know I might get burned in a series of progressive flame wars that will > ensue as a result of the email, but what Maui really needs is clean room > re-implementation that > takes the project out of Adaptive's control. I do not know if a clean room re-implementation is necessary. Although each file of the code contains an end user license which makes it pretty clear that the copyright belongs to Cluster Resources (i.e. Adaptive Computing), this did not stop the birth of Torque, whose code is full of similar statements from Veridian (Altair). We would need a lawyer for this... But rewriting from scratch would certainly permit more modular and better documented software, if it is done correctly from the start. Maui does not have any documentation of its data structures. Maybe a good start would be to document Maui so it becomes more maintainable. If a new scheduler was rewritten from scratch, I think it would be a lot better if the limits were rule-based and interpreted with an inference engine. The local policies could then be much more general. > Where Adaptive may have good intents and purposes for providing a free > implementation of their Moab scheduler, they are > after all a company and if they truly embraced the concept of open source > software, Moab would be free to use and their business model would be > different. But this is > not the case and year after year we watch Maui languish with very few feature > improvements while Moab moves forward with many new features to remain > relevant in the market, which it should. Indeed, Maui (or a successor) needs to understand new Torque syntax (-lprocs, gpus, -L syntax, etc.). We cannot count on Adaptive for this. > Just there should be a project that allows people to contribute in an open, > unhindered manor with the ability to fork the code to foster the culmination > of ideas. I totally agree. The question remains whether we can accomplish this by modifying Maui or by rewriting it from scratch... -- Michel Béland, analyste en calcul scientifique michel.bel...@calculquebec.ca bureau S-250, pavillon Roger-Gaudry (principal), Université de Montréal téléphone : 514 343-6111 poste 3892 télécopieur : 514 343-2155 Calcul Québec (www.calculquebec.ca) Calcul Canada (calculcanada.ca) ___ mauiusers mailing list mauiusers@supercluster.org http://www.supercluster.org/mailman/listinfo/mauiusers
Re: [Mauiusers] Question about Maui data structures
I agree. With our own experience, I found Moab fixing many of Maui's bugs. I came to my own conclusion that Maui was just a stepping stone to Moab.You use the free Maui product which kind-of-works, get hooked using it but when you get down to serious implementation and need a scheduler that actually works, Maui fails in strange weird ways, HOWEVER you can easily "fix" the bugs in Maui by moving to Moab with very little effort. What a coincidence! Joseph On 12/09/2015 02:08 PM, Svancara, Randall wrote: > Hi, > > I know I might get burned in a series of progressive flame wars that will > ensue as a result of the email, but what Maui really needs is clean room > re-implementation that > takes the project out of Adaptive's control. Where Adaptive may have good > intents and purposes for providing a free implementation of their Moab > scheduler, they are > after all a company and if they truly embraced the concept of open source > software, Moab would be free to use and their business model would be > different. But this is > not the case and year after year we watch Maui languish with very few feature > improvements while Moab moves forward with many new features to remain > relevant in the market, which it should. > Just there should be a project that allows people to contribute in an open, > unhindered manor with the ability to fork the code to foster the culmination > of ideas. > > Randall > > > > From: mauiusers-boun...@supercluster.org [mauiusers-boun...@supercluster.org] > on behalf of Michel Béland [michel.bel...@calculquebec.ca] > Sent: Wednesday, December 09, 2015 1:44 PM > To: Joseph Farran > Cc: mauiusers@supercluster.org > Subject: Re: [Mauiusers] Question about Maui data structures > > Hi Joseph, > >> For whatever it is worth, Maui has some serious bugs when it is in >> full use. > We had problems initially when we first used Maui on our big cluster. > Most of them were fixed by increasing some limits in the include files. > We also had a problem with some idle jobs not running (showstart would > show they should run immediately, but they would not). This was fixed by > commenting out some code. This was in a patch published on this list > many years ago, but it never made it to a release. > > The bugs caused by the Torque 5 change in attribute format are really > the show stoppers for us, hence my desire to fix them. > > The others bugs I can live with, for now. > >> I had Maui running for a VERY long time and it would behave >> differently when it was mostly idle as when it was under heavy use - >> we have thousands of cores. >> >> In my frustration I downloaded and enabled "moab" eval and as if by >> magic all of the weirdness we were seeing in Maui went away over a >> 2-month period. After two months of use, when I reverted back to >> Maui, all of the same weirdness came back. >> >> We eventually dropped Maui and went with Son of Grid Engine as Moab >> was price prohibited for us. Grid Engine has been working very well >> albeit via several home grown custom modifications. > Good for you, but Torque still needs a free alternative to Moab. > pbs_sched is out of the question, unless it is heavily modified to add > missing features like backfilling. Maui is the closest approximation to > a usable free scheduler for Torque. It would be nice if users helped to > fix the bugs instead of giving up, but I understand that users do not > necessarly have time, skill or will to do so. > > > -- > Michel Béland, analyste en calcul scientifique > michel.bel...@calculquebec.ca > bureau S-250, pavillon Roger-Gaudry (principal), Université de Montréal > téléphone : 514 343-6111 poste 3892 télécopieur : 514 343-2155 > Calcul Québec (www.calculquebec.ca) > Calcul Canada (calculcanada.ca) > > ___ > mauiusers mailing list > mauiusers@supercluster.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.supercluster.org_mailman_listinfo_mauiusers&d=CwIGaQ&c=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQb-Je7sw&r=NkXvUhCruodxG5DTt2AS-sYyI0M_09ZKGht-b34WJ6I&m=5jGvGXrulMNn4_btnwoLPn-VXyr54C8SI3fTMbL9ZFk&s=ExlJ6MEfD4nYb-deKA31FQlKPjXNhOqR_w7-OumKoAI&e= > ___ mauiusers mailing list mauiusers@supercluster.org http://www.supercluster.org/mailman/listinfo/mauiusers
Re: [Mauiusers] Question about Maui data structures
-- Bas van der Vlies > On 9 dec. 2015, at 22:44, Michel Béland wrote: > > Hi Joseph, > >> For whatever it is worth, Maui has some serious bugs when it is in >> full use. > > We had problems initially when we first used Maui on our big cluster. > Most of them were fixed by increasing some limits in the include files. > We also had a problem with some idle jobs not running (showstart would > show they should run immediately, but they would not). This was fixed by > commenting out some code. This was in a patch published on this list > many years ago, but it never made it to a release. > > The bugs caused by the Torque 5 change in attribute format are really > the show stoppers for us, hence my desire to fix them. > > The others bugs I can live with, for now. > We use Maui with torque 5 and for us everything is ok. We also have moab but that does not support the Maui features that we have implemented and are needed in our environment. >> I had Maui running for a VERY long time and it would behave >> differently when it was mostly idle as when it was under heavy use - >> we have thousands of cores. >> >> In my frustration I downloaded and enabled "moab" eval and as if by >> magic all of the weirdness we were seeing in Maui went away over a >> 2-month period. After two months of use, when I reverted back to >> Maui, all of the same weirdness came back. >> >> We eventually dropped Maui and went with Son of Grid Engine as Moab >> was price prohibited for us. Grid Engine has been working very well >> albeit via several home grown custom modifications. > > Good for you, but Torque still needs a free alternative to Moab. > pbs_sched is out of the question, unless it is heavily modified to add > missing features like backfilling. Maui is the closest approximation to > a usable free scheduler for Torque. It would be nice if users helped to > fix the bugs instead of giving up, but I understand that users do not > necessarly have time, skill or will to do so. > I totally agree. If you have a some patches please send them then we can apply then or put the result on git server. > > -- > Michel Béland, analyste en calcul scientifique > michel.bel...@calculquebec.ca > bureau S-250, pavillon Roger-Gaudry (principal), Université de Montréal > téléphone : 514 343-6111 poste 3892 télécopieur : 514 343-2155 > Calcul Québec (www.calculquebec.ca) > Calcul Canada (calculcanada.ca) > > ___ > mauiusers mailing list > mauiusers@supercluster.org > http://www.supercluster.org/mailman/listinfo/mauiusers ___ mauiusers mailing list mauiusers@supercluster.org http://www.supercluster.org/mailman/listinfo/mauiusers
Re: [Mauiusers] Question about Maui data structures
Hi Michael. That is great you were able to find and fix the bugs. I had some Maui "experts" who were nice enough to trouble shoot the issues with me on our Cluster - we made several changes to no avail. I created accounts for the experts on our HPC cluster and over several weeks period they eventually gave up as they could not figure it out. I too posted the issues but got very little traction/help at that time. For us, using Moab with no other changes, limit changes or anything else other modications other than changing the port and "maui.cfg" to moab.cfg" and using Moab fixed all of our issues.For us it was not a limit issue or any other obvious change.We came to the conclusion that it was internal bugs with Maui that were not easily fixed. I will say that GE user's group is tremendously helpful in comparison to Maui user's list. There is MUCH more activity with GE in the order of 100x more in comparison. Not trying to persuade or change anyone's opinion, but stating my own observations that may help others with similar issues. Best, Joseph https://hpc.oit.uci.edu On 12/09/2015 01:44 PM, Michel Béland wrote: > Hi Joseph, > >> For whatever it is worth, Maui has some serious bugs when it is in >> full use. > > We had problems initially when we first used Maui on our big cluster. > Most of them were fixed by increasing some limits in the include > files. We also had a problem with some idle jobs not running > (showstart would show they should run immediately, but they would > not). This was fixed by commenting out some code. This was in a patch > published on this list many years ago, but it never made it to a release. > > The bugs caused by the Torque 5 change in attribute format are really > the show stoppers for us, hence my desire to fix them. > > The others bugs I can live with, for now. > >> I had Maui running for a VERY long time and it would behave >> differently when it was mostly idle as when it was under heavy use - >> we have thousands of cores. >> >> In my frustration I downloaded and enabled "moab" eval and as if by >> magic all of the weirdness we were seeing in Maui went away over a >> 2-month period. After two months of use, when I reverted back to >> Maui, all of the same weirdness came back. >> >> We eventually dropped Maui and went with Son of Grid Engine as Moab >> was price prohibited for us. Grid Engine has been working very well >> albeit via several home grown custom modifications. > > Good for you, but Torque still needs a free alternative to Moab. > pbs_sched is out of the question, unless it is heavily modified to add > missing features like backfilling. Maui is the closest approximation > to a usable free scheduler for Torque. It would be nice if users > helped to fix the bugs instead of giving up, but I understand that > users do not necessarly have time, skill or will to do so. > > ___ mauiusers mailing list mauiusers@supercluster.org http://www.supercluster.org/mailman/listinfo/mauiusers
Re: [Mauiusers] Question about Maui data structures
Hi Joseph, > For whatever it is worth, Maui has some serious bugs when it is in > full use. We had problems initially when we first used Maui on our big cluster. Most of them were fixed by increasing some limits in the include files. We also had a problem with some idle jobs not running (showstart would show they should run immediately, but they would not). This was fixed by commenting out some code. This was in a patch published on this list many years ago, but it never made it to a release. The bugs caused by the Torque 5 change in attribute format are really the show stoppers for us, hence my desire to fix them. The others bugs I can live with, for now. > I had Maui running for a VERY long time and it would behave > differently when it was mostly idle as when it was under heavy use - > we have thousands of cores. > > In my frustration I downloaded and enabled "moab" eval and as if by > magic all of the weirdness we were seeing in Maui went away over a > 2-month period. After two months of use, when I reverted back to > Maui, all of the same weirdness came back. > > We eventually dropped Maui and went with Son of Grid Engine as Moab > was price prohibited for us. Grid Engine has been working very well > albeit via several home grown custom modifications. Good for you, but Torque still needs a free alternative to Moab. pbs_sched is out of the question, unless it is heavily modified to add missing features like backfilling. Maui is the closest approximation to a usable free scheduler for Torque. It would be nice if users helped to fix the bugs instead of giving up, but I understand that users do not necessarly have time, skill or will to do so. -- Michel Béland, analyste en calcul scientifique michel.bel...@calculquebec.ca bureau S-250, pavillon Roger-Gaudry (principal), Université de Montréal téléphone : 514 343-6111 poste 3892 télécopieur : 514 343-2155 Calcul Québec (www.calculquebec.ca) Calcul Canada (calculcanada.ca) ___ mauiusers mailing list mauiusers@supercluster.org http://www.supercluster.org/mailman/listinfo/mauiusers
Re: [Mauiusers] Question about Maui data structures
Hi.
For whatever it is worth, Maui has some serious bugs when it is in full use.
I had Maui running for a VERY long time and it would behave differently
when it was mostly idle as when it was under heavy use - we have
thousands of cores.
In my frustration I downloaded and enabled "moab" eval and as if by
magic all of the weirdness we were seeing in Maui went away over a
2-month period. After two months of use, when I reverted back to Maui,
all of the same weirdness came back.
We eventually dropped Maui and went with Son of Grid Engine as Moab was
price prohibited for us. Grid Engine has been working very well albeit
via several home grown custom modifications.
Joseph
On 12/09/2015 12:37 PM, Michel Béland wrote:
> Bas van der Vlies wrote:
>
>> Dear Michel,
>>
>> What I read from the code (It is while back that I did that, but we are in
>> the process of patching some maui stuff). The
>> * N-TaskCount is number of jobs on the node
>> * and N->DRes.Procs —> Which resources are given to the consumer,
>>
>> So you can have a node with 16 cores and if you have an share node:
>>* 4 nodes dat consume all cores
> You mean 4 jobs, I guess?
>
>> With the N->DRes.Procs you can determine if there are slot available for
>> other jobs, eg:
>>* 5 jobs each 2 core
>>* N->DRes.Procs will be 10
>>* and still 6 slots available
>>
>> That is what I read.
> Hmm... Looking at the code, I see for example that functions
> MPBSNodeLoad() and MPBSNodeUpdate() in file MPBSI.c both loop on the
> comma-separated tokens of the "jobs" attribute of a node by incrementing
> N->TaskCount for each token. This is a while loop using
>
> ptr = MUStrTok(tmpBuffer,", \t",&TokPtr);
>
> to get the first token and
>
> ptr = MUStrTok(NULL,", \t",&TokPtr);
>
> to get the next one, pretty similar to the C function strtok() and the
> POSIX function strtok_r().
>
> This means that with a jobs attribute looking like this:
>
> 0/48.server, 1/48.server, 2/49.server, 3/49.server
>
> N->TaskCount will end up taking the value 4. It means that it counts the
> number of processors, not the number of jobs on the node.
>
> Lines 3188 to 3209 of MPBSI.c are where MPBSNodeUpdate() treats one
> token by incrementing N->TaskCount and extracting the JobID. That is
> after that it gets interesting. N->DRes.Procs is incremented this way:
>
> 3211if (MJobFind(JobID,&J,0) == SUCCESS)
> 3212 {
> 3213 if (J->Req[0]->DRes.Procs == -1)
> 3214 {
> 3215 tmpProcs = N->CRes.Procs;
> 3216 }
> 3217 else
> 3218 {
> 3219 tmpProcs = MAX(1,J->Req[0]->DRes.Procs);
> 3220 }
> 3221
> 3222 N->DRes.Procs = MIN(N->DRes.Procs + tmpProcs,N->CRes.Procs);
> 3223
>
> If I understand correctly, J->Req[0]->DRes.Procs) is the number of
> processors dedicated to the job. But wait, what tells us that these
> processors are on the current node? The only way I think this code might
> work is if J->Req[0]->DRes.Procs == 0, making tmpProcs equal to 1. Then
> N->DRes.Procs and N->TaskCount are the same...
>
> MPBSNodeLoad() has similar looking code, but nor exactly the same:
>
> 2514 if (MJobFind(JobID,&J,0) == SUCCESS)
> 2515 {
> 2516 N->DRes.Procs += MAX(1,J->Req[0]->DRes.Procs); /* FIXME */
>
> I will experiment with a debugger on an old cluster running an earlier
> version of Torque and see what value J->Req[0]->DRes.Procs has.
>
>
>
>>> On 8 dec. 2015, at 23:09, Michel Béland
>>> wrote:
>>>
>>> Hello,
>>>
>>> I am trying to modify Maui to understand correctly the "exec_host" job
>>> attribute and the "jobs" node attribute. While reading the code, I
>>> wondered what was the meaning of parts of the data structure.
>>>
>>> So what is the difference between N->TaskCount and N->DRes.Procs, where
>>> N is a pointer of type mnode_t? The comments do not help a lot.
>>>
>>> --
>>> Michel Béland, analyste en calcul scientifique
>>> michel.bel...@calculquebec.ca
>>> bureau S-250, pavillon Roger-Gaudry (principal), Université de Montréal
>>> téléphone : 514 343-6111 poste 3892 télécopieur : 514 343-2155
>>> Calcul Québec (www.calculquebec.ca)
>>> Calcul Canada (calculcanada.ca)
>>>
>>> ___
>>> mauiusers mailing list
>>> mauiusers@supercluster.org
>>> http://www.supercluster.org/mailman/listinfo/mauiusers
>> --
>> Bas van der Vlies
>> | Operations, Support & Development | SURFsara | Science Park 140 | 1098 XG
>> Amsterdam
>> | T +31 (0) 20 800 1300 | bas.vandervl...@surfsara.nl | www.surfsara.nl |
>>
>>
>>
>>
>
___
mauiusers mailing list
mauiusers@supercluster.org
http://www.supercluster.org/mailman/listinfo/mauiusers
Re: [Mauiusers] Question about Maui data structures
Bas van der Vlies wrote:
> Dear Michel,
>
> What I read from the code (It is while back that I did that, but we are in
> the process of patching some maui stuff). The
>* N-TaskCount is number of jobs on the node
>* and N->DRes.Procs —> Which resources are given to the consumer,
>
> So you can have a node with 16 cores and if you have an share node:
> * 4 nodes dat consume all cores
You mean 4 jobs, I guess?
> With the N->DRes.Procs you can determine if there are slot available for
> other jobs, eg:
> * 5 jobs each 2 core
> * N->DRes.Procs will be 10
> * and still 6 slots available
>
> That is what I read.
Hmm... Looking at the code, I see for example that functions
MPBSNodeLoad() and MPBSNodeUpdate() in file MPBSI.c both loop on the
comma-separated tokens of the "jobs" attribute of a node by incrementing
N->TaskCount for each token. This is a while loop using
ptr = MUStrTok(tmpBuffer,", \t",&TokPtr);
to get the first token and
ptr = MUStrTok(NULL,", \t",&TokPtr);
to get the next one, pretty similar to the C function strtok() and the
POSIX function strtok_r().
This means that with a jobs attribute looking like this:
0/48.server, 1/48.server, 2/49.server, 3/49.server
N->TaskCount will end up taking the value 4. It means that it counts the
number of processors, not the number of jobs on the node.
Lines 3188 to 3209 of MPBSI.c are where MPBSNodeUpdate() treats one
token by incrementing N->TaskCount and extracting the JobID. That is
after that it gets interesting. N->DRes.Procs is incremented this way:
3211if (MJobFind(JobID,&J,0) == SUCCESS)
3212 {
3213 if (J->Req[0]->DRes.Procs == -1)
3214 {
3215 tmpProcs = N->CRes.Procs;
3216 }
3217 else
3218 {
3219 tmpProcs = MAX(1,J->Req[0]->DRes.Procs);
3220 }
3221
3222 N->DRes.Procs = MIN(N->DRes.Procs + tmpProcs,N->CRes.Procs);
3223
If I understand correctly, J->Req[0]->DRes.Procs) is the number of
processors dedicated to the job. But wait, what tells us that these
processors are on the current node? The only way I think this code might
work is if J->Req[0]->DRes.Procs == 0, making tmpProcs equal to 1. Then
N->DRes.Procs and N->TaskCount are the same...
MPBSNodeLoad() has similar looking code, but nor exactly the same:
2514 if (MJobFind(JobID,&J,0) == SUCCESS)
2515 {
2516 N->DRes.Procs += MAX(1,J->Req[0]->DRes.Procs); /* FIXME */
I will experiment with a debugger on an old cluster running an earlier
version of Torque and see what value J->Req[0]->DRes.Procs has.
>> On 8 dec. 2015, at 23:09, Michel Béland
>> wrote:
>>
>> Hello,
>>
>> I am trying to modify Maui to understand correctly the "exec_host" job
>> attribute and the "jobs" node attribute. While reading the code, I
>> wondered what was the meaning of parts of the data structure.
>>
>> So what is the difference between N->TaskCount and N->DRes.Procs, where
>> N is a pointer of type mnode_t? The comments do not help a lot.
>>
>> --
>> Michel Béland, analyste en calcul scientifique
>> michel.bel...@calculquebec.ca
>> bureau S-250, pavillon Roger-Gaudry (principal), Université de Montréal
>> téléphone : 514 343-6111 poste 3892 télécopieur : 514 343-2155
>> Calcul Québec (www.calculquebec.ca)
>> Calcul Canada (calculcanada.ca)
>>
>> ___
>> mauiusers mailing list
>> mauiusers@supercluster.org
>> http://www.supercluster.org/mailman/listinfo/mauiusers
> --
> Bas van der Vlies
> | Operations, Support & Development | SURFsara | Science Park 140 | 1098 XG
> Amsterdam
> | T +31 (0) 20 800 1300 | bas.vandervl...@surfsara.nl | www.surfsara.nl |
>
>
>
>
--
Michel Béland, analyste en calcul scientifique
michel.bel...@calculquebec.ca
bureau S-250, pavillon Roger-Gaudry (principal), Université de Montréal
téléphone : 514 343-6111 poste 3892 télécopieur : 514 343-2155
Calcul Québec (www.calculquebec.ca)
Calcul Canada (calculcanada.ca)
___
mauiusers mailing list
mauiusers@supercluster.org
http://www.supercluster.org/mailman/listinfo/mauiusers
Re: [Mauiusers] Question about Maui data structures
Dear Michel, What I read from the code (It is while back that I did that, but we are in the process of patching some maui stuff). The * N-TaskCount is number of jobs on the node * and N->DRes.Procs —> Which resources are given to the consumer, So you can have a node with 16 cores and if you have an share node: * 4 nodes dat consume all cores With the N->DRes.Procs you can determine if there are slot available for other jobs, eg: * 5 jobs each 2 core * N->DRes.Procs will be 10 * and still 6 slots available That is what I read. > On 8 dec. 2015, at 23:09, Michel Béland wrote: > > Hello, > > I am trying to modify Maui to understand correctly the "exec_host" job > attribute and the "jobs" node attribute. While reading the code, I > wondered what was the meaning of parts of the data structure. > > So what is the difference between N->TaskCount and N->DRes.Procs, where > N is a pointer of type mnode_t? The comments do not help a lot. > > -- > Michel Béland, analyste en calcul scientifique > michel.bel...@calculquebec.ca > bureau S-250, pavillon Roger-Gaudry (principal), Université de Montréal > téléphone : 514 343-6111 poste 3892 télécopieur : 514 343-2155 > Calcul Québec (www.calculquebec.ca) > Calcul Canada (calculcanada.ca) > > ___ > mauiusers mailing list > mauiusers@supercluster.org > http://www.supercluster.org/mailman/listinfo/mauiusers -- Bas van der Vlies | Operations, Support & Development | SURFsara | Science Park 140 | 1098 XG Amsterdam | T +31 (0) 20 800 1300 | bas.vandervl...@surfsara.nl | www.surfsara.nl | ___ mauiusers mailing list mauiusers@supercluster.org http://www.supercluster.org/mailman/listinfo/mauiusers
