linux-kernel - Re: [PATCH 0/8] Suspend block api (version 6)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100526173252.GC9069@elf.ucw.cz>
Date:	Wed, 26 May 2010 19:32:52 +0200
From:	Pavel Machek <pavel@....cz>
To:	Arve Hj?nnev?g <arve@...roid.com>
Cc:	Matthew Garrett <mjg@...hat.com>,
	Kevin Hilman <khilman@...prootsystems.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Alan Stern <stern@...land.harvard.edu>,
	Tejun Heo <tj@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
	Paul Walmsley <paul@...an.com>, magnus.damm@...il.com,
	mark gross <mgross@...ux.intel.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Geoff Smith <geoffx.smith@...el.com>
Subject: Re: [PATCH 0/8] Suspend block api (version 6)

On Mon 2010-05-24 18:16:15, Arve Hj?nnev?g wrote:
> On Mon, May 24, 2010 at 11:57 AM, Pavel Machek <pavel@....cz> wrote:
> > Hi!
> >
> >> I agree that the runtime scenario is a far more appealing one from an
> >> aesthetic standpoint, but so far we don't have a very compelling
> >> argument for dealing with the starting and stopping of userspace. The
> >> use-cases that Google have provided are valid and they have an
> >> implementation that addresses them, and while we're unable to provide an
> >> alternative that provides the same level of functionality I think we're
> >> in a poor position to prevent this from going in.
> >
> > Uhuh?
> >
> > "We have this ugly code here, but it works and we don't have better
> > one, so lets merge it"?
> >
> > I don't really like this line of reasoning. I would not want to judge
> > wakelocks here, but... "it works, merge it" should not be used as
> > argument.
> >
> > And btw I do have wakelock-less implementation of autosleep, that only
> > sleeped the machine when nothing was ready to run. It was called
> > "sleepy linux". Should I dig it out?
> >
> > Major difference was that it only sleeped the machine when it was
> > absolutely certain machine is idle and no timers are close to firing
> > -- needing elimination or at least markup of all short timers. It
> > erred on side of not sleeping the machine when it would break
> > something.
> >
> 
> How did you handle external events that occur right after you decided to sleep?

I decided to go to sleep with interrupts disabled... it was prototype
on x86, so it was rather tricky.

I'd expect external events after sleep decision to just wakeup machine
immediately, similar to entering deep CPU sleep mode...
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/