mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nigel Cunningham <ncunningham@linuxmail.org>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Dave Jones <davej@redhat.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: peculiar suspend/resume bug.
Date: Thu, 17 Aug 2006 11:44:30 +1000	[thread overview]
Message-ID: <1155779070.3369.44.camel@nigel.suspend2.net> (raw)
In-Reply-To: <20060816024140.GA30814@srcf.ucam.org>

Hi.

On Wed, 2006-08-16 at 03:41 +0100, Matthew Garrett wrote:
> On Tue, Aug 15, 2006 at 08:37:28PM -0400, Dave Jones wrote:
> 
> > cpufreq-applet crashes as soon as the cpu goes offline.
> > Now, the applet should be written to deal with this scenario more
> > gracefully, but I'm questioning whether or not userspace should
> > *see* the unplug/replug that suspend does at all.
> 
> As Nigel mentioned, cpu unplug happens just before processes are frozen, 
> so I guess there's a chance for it to be scheduled. On the other hand, 
> it's not unreasonable for CPUs to be unplugged during runtime anyway - 
> perhaps userspace should be able to deal with that?

Agreed.

I've spent a little more time thinking about this, and want to put a few
thoughts forward for discussion/ignoring/flame bait/whatever.

I see two main issues at the moment with freezing before hotplugging.
The first is that we have cpu specific kernel threads that we're going
to want to kill, and the second is that we have userspace threads that
we want to migrate to another cpu. Have I missed anything?

The first issue could be helped by splitting the freezing of userspace
processes from kernel space. The kernel threads could thus die without
us having to worry about userspace seeing what's going on. I haven't
looked at vanilla in a while; this might already be in. Alternatively,
if it's viable, per-cpu kernel threads could perhaps be made NO_FREEZE.

The second issue is migrating userspace threads. I'm no scheduling
expert, so I'll just speculate :>. I wondered if it's possible to make
the migration happen lazily; in such a way that if, when we come to thaw
userspace, the cpu has been hotplugged again, the migration never
happens. Does that sound possible?

Regards,

Nigel


  parent reply	other threads:[~2006-08-17  1:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-15 22:10 Dave Jones
2006-08-16  0:19 ` Nigel Cunningham
2006-08-16  0:37   ` Dave Jones
2006-08-16  1:05     ` Nigel Cunningham
2006-08-16  2:41     ` Matthew Garrett
2006-08-16  3:53       ` Dave Jones
2006-08-16  8:54         ` Rafael J. Wysocki
2006-08-17  1:44       ` Nigel Cunningham [this message]
2006-08-17  5:44         ` Rafael J. Wysocki
2006-08-17  5:55           ` Nigel Cunningham
2006-08-17  6:30             ` Rafael J. Wysocki
2006-08-16 22:06 ` Pavel Machek

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=1155779070.3369.44.camel@nigel.suspend2.net \
    --to=ncunningham@linuxmail.org \
    --cc=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    /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

Powered by JetHome