On Thu, Sep 24, 2009 at 09:50:10AM +0100, Clive Messer wrote:
> There is a reason for choosing BATCH (as a default) and not IDLE. I alluded
> to
> it above. PPD is not affected on a dedicated cruncher with BATCH. With IDLE
> it
> is reduced by 10%, more with a PREEMPT kernel.
Yes, that's how SCHED_BATCH and SCHED_IDLE works. And I'm saying I
_want_ SCHED_IDLE behavior on my desktop. Yes, I can patch the client
and rip out the call to sched_setscheduler(), but why make it difficult?
Make it configurable, and I won't complain.
> > Debian also uses ionice to set the I/O scheduling class to IDLE, so that
> > should be integrated too. The I/O class should be set for the core
> > client as well, not just for the applications.
>
> It depends on how far you want to take it. The BOINC defaults, nice 19 for
> CPU
> tasks and nice 10 for the GPU tasks already is pretty much the sweet spot and
> those are already hard-coded. Changing the policy to BATCH for the CPU, you
> could argue is the equivalent of just dropping the CPU priority one level
> lower from the hard-coded defaults. It doesn't really affect anything at all
> as
> far as PPD is concerned on a dedicated cruncher but makes the desktop feel a
> lot more responsive on a non-dedicated cruncher. It's a good default without
> configs option or resorting to userland ionice/schedtool etc. etc. The parent
> program (core client) is not exactly CPU intensive so I don't really see the
> need to fiddle with scheduling classes for that.
I did not talk about _CPU_ scheduling regarding the core client. I was
talking about _I/O_ scheduling. The core client can be I/O intensive if
a project has big input/output files or if a project has short WUs and
uses <copy_file/> heavily. Our BOINC computing nodes use a central
storage and we can see clearly on the I/O graphs when they are doing
work and when they are idle.
> One other thing to consider here with both nice and schedule policy, is that
> if the core runs as 'standard' non-superuser, priorities can be decreased but
> not increased. The Fedora packaged script starts the core at nice 19. The
> setpriority call to set the GPU clients to nice 10 is ignored because the non-
> priv user cannot increase the priority above the parent process. Running
> crunchers with 6 and 8 GPU's each this is disastrous with a mix of CPU and
> GPU
> clients all running at nice 19. Starting the core with very low priority or
> schedule policy is not something that I'd want to do. ;)
The problem with your view is that you only care about the amount of
computing power you can get, while I care more about BOINC not getting
in my way. If I start a large parallel compilation, then I want all the
cores to work on it 100% of their time, and I do not want to give any
CPU time to BOINC jobs at all. I'm sitting there waiting for the
compilation to finish, and if it takes longer, then I'll be unhappy.
BOINC can get the CPUs back when the compilation finishes.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
