WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: xenpaing: one way to avoid paging out the page, when the

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Re: xenpaing: one way to avoid paging out the page, when the corresponding mfn is in use.
From: andres@xxxxxxxxxxxxxxxx
Date: Wed, 2 Nov 2011 07:44:45 -0700
Cc: hongkaixing@xxxxxxxxxx
Delivery-date: Wed, 02 Nov 2011 07:45:33 -0700
Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.com; h= message-id:in-reply-to:references:date:subject:from:to:cc :mime-version:content-type:content-transfer-encoding; s= lagarcavilla.com; bh=v1R+WO46sbdkfbcdFLAJ1NcdSZY=; b=Vtekasea27S gtpWCNi6pmknHq418kDADyblIy5vzZM6HsPm/6NruG41AhxL9Bs9fd2CfOBsD0oV xheM4jb4xj1ADnnDTB58qxR+6WtZrMoiIJYWN9AqeUsOYvqplBqc5J9I/CMUa2An rzCLFXkeBccIrwwnAkkr6FUbRstvTP24=
Domainkey-signature: a=rsa-sha1; c=nofws; d=lagarcavilla.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:mime-version :content-type:content-transfer-encoding; q=dns; s= lagarcavilla.com; b=TxcfvXTJCHMDD7LEtci7Vo5Ue5LRcAZ9HOTYR1ykER6R 83kGH6sTgKXGJdE1Gryv7ni2aNAFJaUs4/Gc9hmPQtPmtycY268sPO1JrQcKEQ/s kGXoKwHcvEj3qRmsSVd9o3BjFUTIUIxc85tRnOhRQi++EQPnKsxej6IFPOAdV64=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20111101124941.583FA72C415@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20111101124941.583FA72C415@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: SquirrelMail/1.4.21
Page_info structs are carefully laid out to occupy 64 bytes (I think -- or
some other power of two cache-line-friendly thing).

Were you thinking of this new field to be part of a union? which one?
Otherwise you change the size of page_info and hell breaks loose.

The RFC patches I posted a week ago (which are not ready for primetime)
try to ensure serialization of lookups and modification of p2m entries.
That should solve the issue of paging a foreign-mapped page.

Actually the patches attempt to achieve what you state ("When the page
(mfn) is accessed by gfn_to_mfn(), this page should never be paged out
until the mapping action is end"). And hopefully in a much more general
way.

So, stay posted...

Andres

> Date: Tue, 01 Nov 2011 12:23:37 +0000
> From: Hongkaixing <hongkaixing@xxxxxxxxxx>
> Subject: [Xen-devel] xenpaing: one way to avoid paging out the page,
>       when the corresponding mfn is in use.
> To: "olaf@xxxxxxxxx" <olaf@xxxxxxxxx>
> Cc: YangXiaowei <xiaowei.yang@xxxxxxxxxx>,
>       "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>,        
> "Eric
>       Li\(Zhentao\)" <lizhentao@xxxxxxxxxx>,  Yanqiangjun
>       <yanqiangjun@xxxxxxxxxx>, hanweidong <hanweidong@xxxxxxxxxx>
> Message-ID:
>       
> <E0AF011477D2AE458DC8801E0E570709014C0556@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
>
> Content-Type: text/plain; charset=Windows-1252
>
> Hello,
>
>    Recently many advanced memory mechanisms are introduced into Xen. One
> problem we found is the conflict between p2m query and setting.
>    For example, backend drivers always map domU?s page to its own space,
> during the mapping procedure, situations as follow may happen,
> when mfn is obtained by gfn_to_mfn(), this mfn is likely to be paged out.
>
> first case:
>    grant mapping                      xenpaing
>   mfn = gfn_to_mfn();
>                        <-----------  p2m_paging_nominate()
>          |                                         |
>      Check type ok                     paged out;
>          |
>      try to map
> What we want is:
> When the page (mfn) is accessed by gfn_to_mfn(), this page should never be
> paged out until the mapping action is end.
>
> second case:
>    grant mapping                            xenpaing
>                                          p2m_paging_nominate()
>
>                                                  gfn_to_mfn();
>   mfn = gfn_to_mfn();  ------------->     |
>                                              check type ok
>          |                                               |
>      Check type ok                     paged out;
>          |
>      try to map
> What we want is:
> When the gfn_to_mfn() action happens during paging nomination, the
> nomination should abort immediately.
>
> Our solution prototype is like this :
> 1. Introduce a new member named last_access in page_info struct to save
> the last access time and access tag.
> 2. when the mfn is obtained through gfn_to_mfn(), we save time stamp and
> access tag in the page_info.
> 3. Paging nominate procedure use access information as a criterion.
>
> How it works?
> 1.Using time stamp to avoid case 1. When the mfn is obtained by mapping
> process,
>    the time stamp can prevent the page from being selected by paging .
> 2.Using access tag to avoid case 2. During the paging nomination, if the
> access tag of page is detected,
>    paging should skip selecting this page.
>
> The pseudo-code of step 3 can be written as follow:
> int p2m_mem_paging_nominate(struct domain *d, unsigned long gfn)
> {
>
>     mfn = gfn_to_mfn_noreference(d, gfn, &p2mt);   -----> avoid saving
> timestamp and access tag
>
>     if ( !mfn_valid(mfn) )
>         goto out;
>
>     clear_access_tag();   ----------> clear the access tag of this page
>     if (test_page_hot())
>        goto out;           ------> if the page is accessed recently, go to
> out
>     ........
>
>     set_p2m_entry(d, gfn, mfn, 0, p2m_ram_paging_out);
>     if ( test_access_tag ( mfn ) )
>         goto out;  --------> if access tag is set, the gfn_to_mfn must
> have happened above, abort anyway.
>     ret = 0;
>  out:
>     p2m_unlock(d->arch.p2m);
>     return ret;
> }
>    Maybe this is an imperfect prototype, do you have any good ideas?
>
>   Hong Kaixing
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 01 Nov 2011 13:47:15 +0100
> From: Tobias Heinlein <heinlein@xxxxxxx>
> Subject: Re: [Xen-devel] Re: Xen dom0 linux kernel 3.1 boot failure
>       ptwr_emulate: could not get_page_from_l1e
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Cc: 2013pfoley@xxxxxxxxxx
> Message-ID: <4EAFEA53.7070009@xxxxxxx>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I'm not sure if it was obvious, but yesterday I noticed that setting the
> "MPS table mode" to 'Disabled' actually made SMP stop working, i.e. the
> kernel only recognized a single CPU. This is of course not an option, so
> I enabled (set to 'Full Table APIC') the setting again and played around
> with my kernel config a bit. The kernel that crashed had
> CONFIG_X86_MPPARSE=y, and if I disable that, it boots fine (with SMP,
> and with the BIOS setting set to 'Full Table APIC').
>
> So, I for one am quite happy now as I finally found a working
> configuration. But I'd still like to know if this is a hardware-specific
> issue, and/or a bug in Xen.
>
> Konrad Rzeszutek Wilk wrote, on 10/31/2011 03:08 PM:
>> Oh nice. What does you /proc/interrupts look like compared to
>> baremetal?
>
> While I was performing all my kernel tests, I saved the outputs of
> `dmesg` and `cat /proc/interrupts`. Sorry for attaching a tarball, but
> I'd like to give you as much information as possible. You'll probably
> only need the latest tests (#5 to #7), but just in case, I also included
> the others.
>
> Contents of the tarball:
>
> Baremetal tests:
> xen-hp/1/: MPS mode 'Full Table APIC', CONFIG_X86_MPPARSE=y, SMP working
> xen-hp/2/: MPS mode 'Full Table APIC', CONFIG_X86_MPPARSE=n, SMP working
> xen-hp/3/: MPS mode 'Disabled', CONFIG_X86_MPPARSE=y, SMP not working
> xen-hp/4/: MPS mode 'Disabled', CONFIG_X86_MPPARSE=n, SMP not working
>
> Xen tests:
> xen-hp/5/: MPS mode 'Disabled', CONFIG_X86_MPPARSE=n, SMP not working
> xen-hp/6/: MPS mode 'Full Table APIC', CONFIG_X86_MPPARSE=n, SMP working
> xen-hp/7/: MPS mode 'Full Table APIC', CONFIG_X86_MPPARSE=y, CRASHES
>
> (Therefore, #6 is the best working solution; #7 is what originally
> triggered the crash.)
>
> Thanks.
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: xen-hp.tar.bz2
> Type: application/x-bzip
> Size: 97821 bytes
> Desc: not available
> Url :
> http://lists.xensource.com/archives/html/xen-devel/attachments/20111101/4f96b9e7/xen-hp.tar.bin
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 81, Issue 2
> ****************************************
>



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

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] Re: xenpaing: one way to avoid paging out the page, when the corresponding mfn is in use., andres <=