Linux-kernel mailing list archive 1999-32,: Re: kupdate & laptop's [patch for integration of mobile-update]

# Re: kupdate & laptop's [patch for integration of mobile-update]

Zack Weinberg (zack@bitmover.com)
Sat, 14 Aug 1999 13:02:36 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Gerard Roudier: "Re: New resources - pls, explain :-("
- Previous message: Raul Miller: "Re: Cause of mysterious lock-ups with 2.2.x kernels discovered!"

Peter Englmaier wrote:
> > Yes, you need a:
> >
> > echo 40 500 64 256 0 >/proc/sys/vm/bdflush
> >
> > to disable kupdate. Then it will go to sleep.
> >
> > To reenable kupdate you need to:
> >
> > echo 40 500 64 256 500 >/proc/sys/vm/bdflush
> >
> > and _then_ send it a SIGCONT. (note on Alpha the second 500 has to be
> > close to 5000 since HZ is 1024 there)
>
> Maybe a better fix would be to integrate mobile-update in 'kupdate'?
> I've attached a possible patch to fs/buffer.c below. The idea is based
> on mobile-update, but I simplified it a bit and it checks for activity
> on all IDE(?) disks. I don't know how to make it a compile option,
> yet. Maybe it would be even better to activate mobile-update only if
> running on battery? Anyway, the patch seems to work for me.

I don't believe any of this crud is necessary. My laptop uses 2.2.11
with kupdate, I never disable it, and the disk spins down and stays
spun down. I am convinced that any instance where a disk will not
stay spun down can be tracked to userland bugs or userland
misconfiguration.

The commonly used version of atd will wake up the disk because it
checks for new jobs by rereading the queue directory every so often.
I had to patch it to stat the directory first. Other persistent
daemons may have the same problem - sendmail, lpd, etc. It's not
necessarily safe to stat files, but that information seems to be
cached a lot longer than file/directory data. fstat is always safe,
and so is stat(".").

In the misconfiguration category, you can't have cron jobs that
trigger every few minutes. Nor can you use qmail-spawn or whatever
it's called. Anything that has to happen periodically has to be
handled by a persistent daemon which does not exec. The big problem
here is "rmmod -a" in a cron job. I sent a patch implementing a
trivial daemon to the modutils people, but they never responded.
Another common misconfiguration is if you have syslogd set up to write
--MARK-- into the logs every 20 minutes.

zw

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Gerard Roudier: "Re: New resources - pls, explain :-("
- Previous message: Raul Miller: "Re: Cause of mysterious lock-ups with 2.2.x kernels discovered!"