Hi, Am 29.04.2014 um 22:08 schrieb Michael Stauffer:
> I'm just now able to get back to this post and issue - thanks for all the > answers. With this info and another post that said to set > > execd_params ENABLE_BINDING=TRUE > > binding is working now (at least qstat and taskset show that bindings have > been assigned). > > But I'm wondering how to have a default binding of linear:1, while allowing > the user to override it. The goal is for users who set a parallel environment > to set '-binding linear:N' in there call to qsub, where N is the num of slots > they're requesting. > > If I add '-binding linear:1' to sge_request or $HOME/.sge_request, it works > to set binding, but then when I try to override it in a call to qsub I get > this error: > > [mgstauff@chead ~]$ qsub -binding linear:1 mjob > qsub: Unknown option -binding linear:1 The command: $ qsub -binding linear:1 -binding linear:2 test.sh qsub: Unknown option -binding linear:2 reveals that it complains about specifying it twice. Even using -clear won't help to remove an already set one. It looks like a bug that: a) a -binding cannot be removed individually b) a -binding cannot be altered once it's set c) -clear won't remove it too -- Reuti > I *am* able to override, e.g., a default setting of h_stack. Is there > something particular to binding that doesn't allow this? Anyone know a way > around this? Thanks. > > Or, is there a way to have something in sge_request that automatically sets > binding to the number of requested slots, like '-binding linear:$num_slots' ? > > -M > > > Message: 1 > Date: Wed, 26 Mar 2014 08:23:51 -0400 > From: Bill Bryce <[email protected]> > To: Andreas Haupt <[email protected]> > Cc: [email protected] > Subject: Re: [gridengine users] limit jobs to N core? > Message-ID: <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > > On Mar 26, 2014, at 6:43 AM, Andreas Haupt <[email protected]> wrote: > > > Hi Reuti, > > > > On Wed, 2014-03-26 at 11:29 +0100, Reuti wrote: > >>> AFAIK this is done on a best-effort basis. As long as 4 consecutive > >>> cores are available, jobs will be limited that way. If not, jobs might > >>> even be bound to cores spread over different cpus on multi-socket > >> > >> My understanding is, that there is no binding in certain cases. There are > >> two occurrences in `man qsub` section "-binding / linear" reading "If this > >> is not possible then binding is not done." Binding in SGE is a kind of > >> soft request, which might or might not be fulfilled. > > As Reuti mentioned binding is a soft request in SGE but UGE works > differently. It is a hard request and is controlled by the qmaster not just > the execd as in other versions of Grid Engine. Daniel Gruber can explain it > better than me because he implemented it. > > Bill. > > > > > Just have access to the UGE man page (hope, it's ok to post parts of it > > here ...): > > > > --- > > linear means that Univa Grid Engine tries to bind the job > > on > > amount successive cores. If socket and core is omitted > > then > > Univa Grid Engine first allocates successive cores on the > > first > > empty socket found. Empty means that there are no jobs bound > > to > > the socket by Univa Grid Engine. If this is not possible or > > is > > not sufficient Univa Grid Engine tries to find (further) > > cores > > on the socket with the most unbound cores and so on. If > > the > > amount of allocated cores is lower than requested cores, > > no > > binding is done for the job. > > --- > > > > For me this sounds more like the behaviour I suggested, but my > > understanding might be wrong here ... Maybe there's even a difference in > > the implementation between UGE and SoGE/OGS now. > > > > Cheers, > > Andreas > > -- > > | Andreas Haupt | E-Mail: [email protected] > > | DESY Zeuthen | WWW: http://www-zeuthen.desy.de/~ahaupt > > | Platanenallee 6 | Phone: +49/33762/7-7359 > > | D-15738 Zeuthen | Fax: +49/33762/7-7216 > > > > > > _______________________________________________ > > users mailing list > > [email protected] > > https://gridengine.org/mailman/listinfo/users > > _______________________________________________ > users mailing list > [email protected] > https://gridengine.org/mailman/listinfo/users _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
