From: "Jan Beulich" <jbeulich@novell.com>
To: Keir Fraser <keir@xensource.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: Fwd: Re: struct page field arrangement
Date: Fri, 16 Mar 2007 15:15:35 +0000 [thread overview]
Message-ID: <45FAC2A7.76E4.0078.0@novell.com> (raw)
In-Reply-To: <C2205A88.BAAE%keir@xensource.com>
>>> Keir Fraser <keir@xensource.com> 16.03.07 15:30 >>>
>On 16/3/07 14:13, "Keir Fraser" <keir@xensource.com> wrote:
>
>> Either we are in stop_machine context, or we have offlined all other CPUs
>> via cpu hotplug. In the absence of involuntary preemption it's therefore
>> safe to proceed without locking. But probably inadvisable (we'd like to
>> support full CONFIG_PREEMPT sometime in the future)... I think the 386 code
>> should be changed to match x86/64.
>
>Actually it's not so easy. We walk the pgd_list and so do not have the mm
>associated with the pgd. And in some cases there may not be an mm, if we
>walk the list after a pgd is allocated but before it is attached to an mm.
But without being attached to an mm, the user portion of the pgd should
be blank? I really can't follow why i386 requires so much more special handling
here than x86-64.
>So I think we should simply disable preemption in the i386 case. Which is
>done easily by simply taking the pgd_lock (which it would be polite to do
>anyway, since we're walking the pgd_list). With preemption disabled we're
>definitely safe because pinning is non-blocking and all other CPUs are
>safely spinning in stop_machine or have been offlined.
And what about the pgd_test_and_unpin() case?
>Actually preemption is already disabled by the caller (for a different
>reason) but it's not nice to rely on that.
Jan
next prev parent reply other threads:[~2007-03-16 15:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-16 13:47 Fwd: Re: struct page field arrangement Jan Beulich
2007-03-16 14:13 ` Keir Fraser
2007-03-16 14:30 ` Keir Fraser
2007-03-16 15:15 ` Jan Beulich [this message]
2007-03-16 15:30 ` Keir Fraser
-- strict thread matches above, loose matches on Subject: below --
2007-03-16 11:58 Jan Beulich
2007-03-16 12:11 ` Keir Fraser
2007-03-16 12:25 ` Keir Fraser
2007-03-16 12:54 ` Jan Beulich
2007-03-16 12:37 ` Keir Fraser
2007-03-16 12:46 ` Jan Beulich
2007-02-28 14:31 Jan Beulich
2007-02-28 21:08 ` Hugh Dickins
2007-03-01 8:42 ` Fwd: " Jan Beulich
2007-03-01 10:22 ` Keir Fraser
2007-03-01 11:45 ` Jan Beulich
2007-03-01 12:12 ` Keir Fraser
2007-03-01 12:50 ` Jan Beulich
2007-03-01 13:42 ` Keir Fraser
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=45FAC2A7.76E4.0078.0@novell.com \
--to=jbeulich@novell.com \
--cc=keir@xensource.com \
--cc=xen-devel@lists.xensource.com \
/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.