From: Pavel Machek <pavel@ucw.cz>
To: Nigel Cunningham <ncunningham@linuxmail.org>
Cc: kernel list <linux-kernel@vger.kernel.org>
Subject: Re: Suspend2 merge: 1/51: Device trees
Date: Fri, 26 Nov 2004 00:26:12 +0100 [thread overview]
Message-ID: <20041125232612.GJ2711@elf.ucw.cz> (raw)
In-Reply-To: <1101423148.27250.110.camel@desktop.cunninghams>
Hi!
> > > I thought I wrote - perhaps I'm wrong here - that I understand that your
> > > new work in this area might make this unnecessary. I really only want to
> > > do it this way because I don't know what other drivers might be doing
> > > while we're writing the LRU pages. I'm not worried about them touching
> > > LRU. What I am worried about is them allocating memory and starving
> > > suspend so that we get hangs due to being oom. If they're suspended, we
> > > have more certainty as to how memory is being used. I don't remember
> > > what prompted me to do this in the first place, but I'm pretty sure it
> > > would have been a real observed issue.
> >
> > Uh... It seems like quite a lot of work. Would not reserving few more
> > pages help here? Or perhaps right solution is to fix "broken" drivers
> > that need too much memory...
>
> I'd agree, except that I don't know how many to allocate. It makes
> getting a reliable suspend the result of guess work and favourable
> circumstances. Fixing 'broken' drivers by really suspending them seems
> to me to be the right solution. Make their memory requirements perfectly
> predictable.
Except for the few drivers that are between suspend device and
root. So you still have the same problem, and still need to
guess. Plus you get complex changes to driver model.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
next prev parent reply other threads:[~2004-11-26 19:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20041125165413.GB476@openzaurus.ucw.cz>
2004-11-25 18:53 ` Suspend2 merge: 1/51: Device trees Pavel Machek
2004-11-25 22:22 ` Nigel Cunningham
2004-11-25 22:41 ` Pavel Machek
2004-11-25 22:52 ` Nigel Cunningham
2004-11-25 23:26 ` Pavel Machek [this message]
2004-11-25 23:52 ` Nigel Cunningham
2004-11-26 0:20 ` Pavel Machek
2004-11-27 16:12 ` hugang
2004-11-27 16:13 ` hugang
2004-11-27 16:23 ` Pavel Machek
2004-11-24 12:56 Suspend 2 merge Nigel Cunningham
2004-11-24 12:56 ` Suspend2 merge: 1/51: Device trees Nigel Cunningham
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=20041125232612.GJ2711@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=ncunningham@linuxmail.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 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.