[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
pgds/puds/pmds/ptes...

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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