From: Pavel Machek <pavel@ucw.cz>
To: Ingo Molnar <mingo@elte.hu>
Cc: kernel list <linux-kernel@vger.kernel.org>,
Linux-pm mailing list <linux-pm@lists.osdl.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: [RFC] sleepy linux
Date: Tue, 8 Jan 2008 20:15:20 +0100 [thread overview]
Message-ID: <20080108191519.GA1690@elf.ucw.cz> (raw)
In-Reply-To: <20080108163744.GB13746@elte.hu>
Hi!
>
> > > a quick feature request: could you please make the wake-on-RTC
> > > capability generic and add a CONFIG_DEBUG_SUSPEND_ON_RAM=y config
> > > option (disabled by default) that does a short 1-second
> > > suspend-to-RAM sequence upon bootup? That way we could test s2ram
> > > automatically (which is a MUCH needed feature for automated
> > > regression testing and automatic bisection). In addition, some sort
> > > of 'suspend for N seconds' /sys or /dev/rtc capability would be nice
> > > as well.
> >
> > Hmm, are you sure it is good idea to do this from kernel? I guess this
> > is better done from script...
>
> i have this low-prio effort to make all self-checks automatically
> available via 'make randconfig' as well, for all features that have no
> natural exposure during normal bootup. So far we've got rcutorture,
> kprobes-check, locking/lockdep-self-test and a handful of others.
> External scripts tend to go out of sync and LTP takes way too much time
> to finish.
Well, I can give you a three liner, and if it stops working, I'll
treat is as a regression, because userland ABI changed...?
Or you can get about 10 lines of C, no problem, but I do not think
that should be merged to Linus.
> > > btw., how far are you from having a working prototype?
> >
> > SCSI/SATA issues stop me just now, but even if I get that to work, it
> > will be extremely disgusting hack... and it is unclear how to do it
> > nicely :-(.
>
> as long as the sleep periods are within say 10-20 seconds, and our s2ram
> cycle is fast and optimal enough, we could do this with networking
> enabled too, without dropping/stalling TCP connections left and
> right.
I do not think TCP would survive "10 seconds sleep, 1 second up". But...
> (Perhaps if we could notify routers that they should batch packets for N
> seconds and we could turn off PHY during that time, it would be even
> nicer - is there any such router extension in existence?)
...yes, we should probably play with the routers.
> but if it's nothing else but a s2ram debug/stress utility, that alone
> would be great too :-)
I expect to stress s2ram way too much ;-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
prev parent reply other threads:[~2008-01-08 19:15 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-25 23:07 [RFC] sleepy linux Pavel Machek
2007-12-26 17:28 ` Oliver Neukum
2007-12-26 17:28 ` Oliver Neukum
2007-12-26 19:02 ` Pavel Machek
2007-12-26 19:02 ` Pavel Machek
2007-12-26 20:17 ` Pavel Machek
2007-12-26 20:17 ` Pavel Machek
2007-12-26 20:23 ` Oliver Neukum
2007-12-26 20:23 ` Oliver Neukum
2007-12-26 20:32 ` Pavel Machek
2007-12-26 20:32 ` Pavel Machek
2007-12-26 23:15 ` Oliver Neukum
2007-12-29 23:48 ` Pavel Machek
2007-12-27 9:41 ` Oliver Neukum
2007-12-29 23:51 ` Pavel Machek
2007-12-30 16:39 ` Oliver Neukum
2007-12-31 14:44 ` Pavel Machek
2008-01-02 10:52 ` Oliver Neukum
2007-12-26 18:56 ` H. Peter Anvin
2007-12-26 19:00 ` Pavel Machek
2007-12-26 19:22 ` H. Peter Anvin
2007-12-26 20:08 ` Oliver Neukum
2007-12-26 20:08 ` Oliver Neukum
2007-12-26 20:43 ` H. Peter Anvin
2007-12-26 20:51 ` Pavel Machek
2007-12-26 20:54 ` H. Peter Anvin
2007-12-29 23:44 ` Pavel Machek
2007-12-26 20:09 ` [linux-pm] " Igor Stoppa
2007-12-30 11:15 ` Ingo Molnar
2008-01-05 21:51 ` Pavel Machek
2008-01-08 16:37 ` Ingo Molnar
2008-01-08 19:15 ` Pavel Machek [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080108191519.GA1690@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.osdl.org \
--cc=mingo@elte.hu \
--cc=rjw@sisk.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.