[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Fwd: Re: struct page field arrangement

  • To: Jan Beulich <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Thu, 01 Mar 2007 10:22:24 +0000
  • Delivery-date: Thu, 01 Mar 2007 02:21:43 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acdb64DRvxwMjMfeEduJ9AAX8io7RQ==
  • Thread-topic: [Xen-devel] Fwd: Re: struct page field arrangement

On 1/3/07 08:42, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> Having looked a little into the disabled SPLIT_PT_LOCK issue on Xen, I
> realized that is shouldn't be too difficult to re-enable it (at least in some
> cases).

How does pagetable locking work in modern Linux kernels? It seems that
updates of ptes are protected by a per-page lock or the mm lock, and
population of page directory entries is protected by the mm lock, but that
there is no synchronisation with read-only pagetable walks. Does this mean
that sections of pagetable hierarchy are never reaped from a process until
it dies?

Can we confident that the mm_pin/mm_unpin code (which walks pagetables and
has to find every page to make every one read-only or writable) is safe?
Presumably for this to be true we need to be sure that noone can meanwhile
concurrently be populating the pagetable we are walking with extra

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.