Hi.
On Fri, 2007-04-27 at 16:52 +0200, Pavel Machek wrote:
> Hi!
>
> > From: Nigel Cunningham <nigel@xxxxxxxxxxxxxxxxxx>
> >
> > As explained by Nigel, Sendmail and some other programs look at the
> > load average and stop delivering when it gets too high. The CPU
> > intensiveness of suspending to disk pushes the load average up quite
> > high but post-resume we shouldn't really take that into account. Not
> > updating the load average therefore makes snapshot/shutdown invisible
> > to sendmail and so on.
>
> Is it kernel problem? We _had_ high load, and load average goes down
> pretty quickly.
Don't make artificial distinctions between kernelspace and userspace.
The load average doesn't go down that quickly, and the intensiveness of
the work can make the load average _really_ high. Remember that you're
probably not seeing this because you do an atomic copy pretty quickly.
If you're compressing and writing 80% of ram to disk before the atomic
copy, what will your load average be at the end of that?
> > @@ -1253,9 +1254,18 @@ static inline void calc_load(unsigned lo
> > if (unlikely(count < 0)) {
> > active_tasks = count_active_tasks();
> > do {
> > - CALC_LOAD(avenrun[0], EXP_1, active_tasks);
> > - CALC_LOAD(avenrun[1], EXP_5, active_tasks);
> > - CALC_LOAD(avenrun[2], EXP_15, active_tasks);
> > + /*
> > + * If we let the load average be updated while
> > + * snapshot/shutdown, it will be very high
> > + * post resume. Processes such as some MTAs
> > + * that stop work while the average is high
> > + * will be unnecessarily disrupted.
> > + */
> > + if (likely(!freezer_is_on())) {
> > + CALC_LOAD(avenrun[0], EXP_1, active_tasks);
> > + CALC_LOAD(avenrun[1], EXP_5, active_tasks);
> > + CALC_LOAD(avenrun[2], EXP_15, active_tasks);
> > + }
> > count += LOAD_FREQ;
> > } while (count < 0);
> > }
>
> NAK. This slows down regular operation, at it is 30 lines for what
> should have been one (or five).
Count them. It is one line (an if statement) plus seven lines of
comment.
> Just place avenrun[0] = avenrun[1] = avenrun[2] = 0 at strategic place
> if you feel strongly about this. Additional points for using Rafael's
> "suspend done" notifier so that you don't have to modify suspend core.
=0 might not be right. If you did have a high load average prior to
suspending, not delivering email would be the right thing to do.
Nigel
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
