public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
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

      reply	other threads:[~2008-01-08 19:15 UTC|newest]

Thread overview: 26+ 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 19:02   ` Pavel Machek
2007-12-26 20:17   ` Pavel Machek
2007-12-26 20:23     ` Oliver Neukum
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: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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox