From: "Michael Frank" <mhf@linuxmail.org>
To: "Pavel Machek" <pavel@suse.cz>
Cc: "Andrea Arcangeli" <andrea@suse.de>,
"Nigel Cunningham" <ncunningham@users.sourceforge.net>,
linux-kernel@vger.kernel.org
Subject: Re: Reserved page flaging of 2.4 kernel memory changed recently?
Date: Fri, 20 Feb 2004 01:59:49 +0800 [thread overview]
Message-ID: <opr3mplzb44evsfm@smtp.pacific.net.th> (raw)
In-Reply-To: <20040219173514.GD259@elf.ucw.cz>
On Thu, 19 Feb 2004 18:35:14 +0100, Pavel Machek <pavel@suse.cz> wrote:
> Hi!
>
>> >That means that PG_nosave | PG_reserved indeed is "PG_donttouch", but
>> >PG_nosave has slightly different meaning.
>>
>> Makes sense, but PG_reserved is used to keep VM out of these pages.
>>
>> Can we have a seperate bit PG_donttouch which is set with PG_nosave
>> | PG_reserved in reserved/video/BIOS/Broken CPU areas?
>
> Why?
>
> I do not see what is wrong with 2 separate flags... In fact, you might
> want to
>
> #define PG_donttouch (PG_reserved | PG_nosave)
>
> and (modulo atomic macros etc), it would work for everyone...
>
As your earlier post pointed out, it would not work in swsusp nosave area
which is only PG_reserved | PG_nosave.
Are we too short of bits ? ;)
What about:
- export swsusp __nosave range for netdump override to dump __nosave page(s)
- debugger (linked in) uses swsusp __nosave range to enable access to __nosave page(s)
Regards
Michael
prev parent reply other threads:[~2004-02-19 17:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-05 2:07 Michael Frank
2004-02-08 2:06 ` Andrea Arcangeli
2004-02-10 15:24 ` Michael Frank
2004-02-10 18:51 ` Andrea Arcangeli
2004-02-10 19:38 ` Michael Frank
2004-02-11 8:36 ` Michael Frank
2004-02-19 7:26 ` Pavel Machek
2004-02-19 9:00 ` Michael Frank
2004-02-19 16:14 ` Pavel Machek
2004-02-19 17:37 ` Michael Frank
2004-02-19 17:35 ` Pavel Machek
2004-02-19 17:59 ` Michael Frank [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=opr3mplzb44evsfm@smtp.pacific.net.th \
--to=mhf@linuxmail.org \
--cc=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=ncunningham@users.sourceforge.net \
--cc=pavel@suse.cz \
/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
all inboxes | Powered by JetHome®