David, I just wanted to thank you again for making this change, to set any GPU task at Below Normal priority.
Tonight, GPUGrid (my main GPU project) ran out of work (which happens from time to time), and I stumbled upon some SETI tasks (which is one of my backup GPU projects). The tasks were OpenCL, which meant that they used a full CPU. For some reason, the project doesn't ship the tasks with CPU Usage set to "1.00". So, I set my app_config to properly budget a full CPU for the task, using the plan_class setting to ensure only OpenCL is configured this way, and restarted BOINC (to get the change to be reflected in the UI for my sanity, I wish we could fix this so a restart isn't required).... then I was pleasantly surprised to see Task Manager show it running at Below Normal, and all of my things running on my machine were meshing real well with each other. This isn't the first time I've tested this scenario, but it makes me happy each time it works. So, I'm glad you made you this change. Thank you again. Jacob > From: jacob_w_kl...@msn.com > To: da...@ssl.berkeley.edu; r.haselgr...@btopenworld.com > Date: Fri, 13 Feb 2015 19:14:49 -0500 > CC: boinc_dev@ssl.berkeley.edu > Subject: Re: [boinc_dev] set app priority > > Hallelujah! This is the right call. Now, when a GPU task needs a full CPU > core to keep itself fed, it won't have to compete against the CPU-only tasks. > Hurray! ::does funky nerd dance:: Now POEM can properly set their GPU apps > to use 1.0 CPU, and it'll work correctly! > > Now, just so you know, I believe that GPUGrid is breaking new ground with old > server code. They have a new beta app they're testing, where the app itself > is set up as an MT app, but it also requires an AMD GPU to run it. It's the > first ever "MT + GPU" hybrid app that I've ever seen or heard of, and I think > they're using the MT-style "app plan class shtuff etc." to pull it off. And > they're not going to upgrade server code any time soon, from what they've > said. > > I don't have an AMD GPU, and so I haven't tested it, but I wanted you to be > aware of its existence. It's an oddball. Perhaps one day I'll get an AMD GPU > in this rig, so I can test it. I love testing oddballs. > > Thanks for making the code change here. > > Sincerely, > Jacob > > > > > > Date: Fri, 13 Feb 2015 16:07:00 -0800 > > From: da...@ssl.berkeley.edu > > To: jacob_w_kl...@msn.com; r.haselgr...@btopenworld.com > > CC: boinc_dev@ssl.berkeley.edu > > Subject: Re: [boinc_dev] set app priority > > > > I checked in a change that will run coprocessor jobs at BELOW_NORMAL, > > even if they use >= 1 CPU. > > -- David > > > > On 29-Jan-2015 1:28 PM, Jacob Klein wrote: > > > David, > > > > > > I expect coprocessor jobs (including gpu jobs), to be set at a higher > > > priority than > > > cpu jobs, in order to keep those "other devices" fed. It has a meaningful > > > impact on > > > the task completion times, for GPU tasks as well as ASIC tasks. > > > > > > I still maintain that it should be set as: > > > If (coprocessor job) > > > ... set process priority to BELOW_NORMAL_PRIORITY_CLASS (which I think > > > uses default > > > thread prio of 6 on Windows) > > > Else (cpu job) > > > ... set process priority to IDLE_PRIORITY_CLASS (which I think uses > > > default thread > > > prio of 4 on Windows) > > > > > > We already do this today, except as Richard mentioned, we are erroneously > > > making > > > "full-cpu-core GPU tasks" get bumped to the lower priority, affecting my > > > ability to > > > keep my GPUs loaded, and thus affected task completion time. > > > > > > Could we please change it to "detect that it's a coprocessor job" > > > somehow, when > > > determining priorities, per my recommendation above? > > > I understand your concern about this, but keep in mind these priorities > > > are all > > > lower than NORMAL_PRIORITY_CLASS. > > > > > > So, can we please fix it? > > > > > > > > > > > > ------------------------------------------------------------------------------------ > > > Date: Thu, 29 Jan 2015 20:59:06 +0000 > > > From: r.haselgr...@btopenworld.com > > > Subject: Re: [boinc_dev] set app priority > > > To: da...@ssl.berkeley.edu; jacob_w_kl...@msn.com > > > CC: boinc_dev@ssl.berkeley.edu > > > > > > Maybe we're simply using the wrong discriminant to choose which priority > > > to set. > > > > > > You note that some GPU apps perform poorly at idle priority. > > > > > > But at present we're determining their GPU-ness, not directly, but > > > indirectly by > > > their fractional CPU assignment. > > > > > > There are other GPU apps, apart from the POEM example, where a full 1.00 > > > CPU > > > assignment makes a significant difference in processing time - the > > > Einstein@Home > > > OpenCL application for imtel_gpu is a case in point. > > > > > > Would it not be possible to determine the required priority directly from > > > the 'use > > > GPU' definition instead, and ignore the CPU fraction? > > > > > > > > > ------------------------------------------------------------------------------------ > > > *From:* David Anderson <da...@ssl.berkeley.edu> > > > *To:* Jacob Klein <jacob_w_kl...@msn.com> > > > *Cc:* BOINC Development <boinc_dev@ssl.berkeley.edu> > > > *Sent:* Thursday, January 29, 2015 8:42 PM > > > *Subject:* Re: [boinc_dev] set app priority > > > > > > Jacob: > > > BOINC runs CPU jobs at idle priority to avoid impacting > > > the performance of non-BOINC programs. > > > The rationale for running jobs that use < 1 CPU at higher priority is > > > that > > > - because they use little CPU time, running them at higher priority > > > won't have much impact on other programs > > > - some apps (like QCN, and GPU apps) perform poorly if run at idle > > > priority > > > > > > We could change the policy to run coprocessor apps at higher priority, > > > regardless of how much CPU they use. > > > But that would impact system performance in some cases. > > > I'd hesitate to make this the default. > > > Maybe it could be a cc_config.xml option. > > > > > > -- David > > > > > > On 26-Jan-2015 2:23 PM, Jacob Klein wrote: > > > > Hi David, > > > > > > > > I've been running POEM@Home GPU tasks, with an app_config.xml > > > file, with > > > <cpu_usage> > > > > set to 1.000, since each of their GPU tasks uses a full core, and > > > I want to > > > > appropriately budget resources on my system. > > > > > > > > However, when I do that, the task's process runs at Idle priority, > > > instead of > > > Below > > > > Normal. > > > > > > > > Martin (a dev at Poem@Home) is researching the issue, here: > > > > http://boinc.fzk.de/poem/forum_thread.php?id=1105&postid=10200 > > > > And I replied here: > > > > http://boinc.fzk.de/poem/forum_thread.php?id=1105&postid=10201 > > > > > > > > ... but I think it's being caused by your changes below. > > > > Is your logic below, possibly incorrect? I mean, to my knowledge, > > > there are > > > some GPU > > > > apps (especially OpenCL) which require a full CPU core, and we'd > > > still want their > > > > priorities to be kept at Below Normal, to keep the GPU fed with > > > kernels, as a > > > > priority over other CPU jobs. I could even imagine non-GPU > > > coprocessor jobs that > > > > would also require a full CPU core. > > > > > > > > Thoughts? > > > > > > > > Thanks, > > > > Jacob Klein > > > > > > > > > > > > > > > > > > > > > Date: Thu, 9 Oct 2014 14:49:49 -0700 > > > > > From: da...@ssl.berkeley.edu <mailto:da...@ssl.berkeley.edu> > > > > > To: jacob_w_kl...@msn.com <mailto:jacob_w_kl...@msn.com>; > > > boinc_dev@ssl.berkeley.edu <mailto:boinc_dev@ssl.berkeley.edu> > > > > > Subject: Re: [boinc_dev] set app priority > > > > > > > > > > Currently, when the client runs an app: > > > > > > > > > > - if the app version uses < 1 CPU or has the is_wrapper flag > > > set, > > > > > set the priority to BELOW_NORMAL_PRIORITY_CLASS > > > > > - otherwise set the priority to IDLE_PRIORITY_CLASS > > > > > > > > > > So GPU apps (if they use < 1 CPU), non-CPU-intensive apps, and > > > wrappers > > > > > are run at Below Normal. > > > > > > > > > > When the BOINC wrapper runs an app: > > > > > > > > > > - if <no_priority_change/> is set in the job description file, > > > > > the process inherits the priority of the wrapper > > > > > (normally BELOW_NORMAL_PRIORITY_CLASS) > > > > > - otherwise set the priority to IDLE_PRIORITY_CLASS > > > > > > > > > > There's no provision for anything other than Idle and Below > > > Normal. > > > > > > > > > > (The above is Windows, of course; it's analogous on Unix). > > > > > > > > > > -- David > > > > > > > > > > On 09-Oct-2014 1:26 PM, Jacob Klein wrote: > > > > > > Does this support running the task's process at a priority > > > that is > > > neither Normal > > > > > > (8) nor Idle (4)? > > > > > > GPU apps, for instance, are best run at Below Normal (6) > > > (which GPUGrid > > > somehow > > > > > > does)... and I feel that ASIC apps also should run at Below > > > Normal (6). > > > > > > > > > > > > > > > > > > > > > > > > > Date: Thu, 9 Oct 2014 12:38:16 -0700 > > > > > > > From: da...@ssl.berkeley.edu <mailto:da...@ssl.berkeley.edu> > > > > > > > To: boinc_dev@ssl.berkeley.edu > > > <mailto:boinc_dev@ssl.berkeley.edu> > > > > > > > Subject: Re: [boinc_dev] set app priority > > > > > > > > > > > > > > To address this problem, I added a <no_priority_change/> > > > option > > > > > > > in the wrapper's job description file: > > > > > > > http://boinc.berkeley.edu/trac/wiki/WrapperApp > > > > > > > > > > > > > > This tells the wrapper to not lower the priority of the > > > tasks' process. > > > > > > > > > > > > > > -- David > > > > > > > > > > > > > > On 09-Oct-2014 1:45 AM, Rebirther wrote: > > > > > > > > The <is_wrapper/> option doesnt work for me, the wrapper > > > is still in > > > normal > > > > > > > > priority as before and the app in lowest priority running > > > BOINC > > > client 7.4.22 > > > > > > > > > > > > > > > > -Reb _______________________________________________ > > > boinc_dev > > > mailing list > > > > > > > > boinc_dev@ssl.berkeley.edu > > > <mailto:boinc_dev@ssl.berkeley.edu> > > > > > > > > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > > > To > > > unsubscribe, visit > > > > > > > > the above URL and (near bottom of page) enter your email > > > address. > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > boinc_dev mailing list > > > > > > > boinc_dev@ssl.berkeley.edu > > > <mailto:boinc_dev@ssl.berkeley.edu> > > > > > > > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > > > > > > > To unsubscribe, visit the above URL and > > > > > > > (near bottom of page) enter your email address. > > > _______________________________________________ > > > boinc_dev mailing list > > > boinc_dev@ssl.berkeley.edu <mailto:boinc_dev@ssl.berkeley.edu> > > > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > > > To unsubscribe, visit the above URL and > > > (near bottom of page) enter your email address. > > > > > > > > _______________________________________________ > boinc_dev mailing list > boinc_dev@ssl.berkeley.edu > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
