Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Xen: Devel

Load increase after memory upgrade (part2)

 

 

First page Previous page 1 2 3 Next page Last page  View All Xen devel RSS feed   Index | Next | Previous | View Threaded


konrad.wilk at oracle

Feb 15, 2012, 11:28 AM

Post #51 of 66 (543 views)
Permalink
Re: Load increase after memory upgrade (part2) [In reply to]

On Wed, Jan 25, 2012 at 08:06:12PM +0100, Carsten Schiers wrote:
> Some news: in order to prepare a clean setting, I upgraded to 3.2.1 kernel. I noticed that the load increase is
> reduced a bit, but noticably. It's only a simple test, running the DomU for 2 minutes, but the idle load is aprox.
>
> - 2.6.32 pvops 12-13%
> - 3.2.1 pvops 10-11%
> - 2.6.34 XenoLinux 7-8%

I took a stab at Jan's idea - it compiles but I hadn't been able to properly test it.
Attachments: vmalloc_using_xen_limit_pages.patch (6.68 KB)


JBeulich at suse

Feb 16, 2012, 12:56 AM

Post #52 of 66 (535 views)
Permalink
Re: Load increase after memory upgrade (part2) [In reply to]

>>> On 15.02.12 at 20:28, Konrad Rzeszutek Wilk <konrad.wilk [at] oracle> wrote:
>@@ -1550,7 +1552,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> struct page **pages;
> unsigned int nr_pages, array_size, i;
> gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
>-
>+ gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
>+ if (xen_pv_domain()) {
>+ if (dma_mask == (__GFP_DMA | __GFP_DMA32))

I didn't spot where you force this normally invalid combination, without
which the change won't affect vmalloc32() in a 32-bit kernel.

>+ gfp_mask &= (__GFP_DMA | __GFP_DMA32);

gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);

Jan

>+ }
> nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
> array_size = (nr_pages * sizeof(struct page *));
>



_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xensource.com/xen-devel


konrad.wilk at oracle

Feb 17, 2012, 7:07 AM

Post #53 of 66 (537 views)
Permalink
Re: Load increase after memory upgrade (part2) [In reply to]

On Thu, Feb 16, 2012 at 08:56:53AM +0000, Jan Beulich wrote:
> >>> On 15.02.12 at 20:28, Konrad Rzeszutek Wilk <konrad.wilk [at] oracle> wrote:
> >@@ -1550,7 +1552,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> > struct page **pages;
> > unsigned int nr_pages, array_size, i;
> > gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
> >-
> >+ gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
> >+ if (xen_pv_domain()) {
> >+ if (dma_mask == (__GFP_DMA | __GFP_DMA32))
>
> I didn't spot where you force this normally invalid combination, without
> which the change won't affect vmalloc32() in a 32-bit kernel.
>
> >+ gfp_mask &= (__GFP_DMA | __GFP_DMA32);
>
> gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);
>
> Jan

Duh!
Good eyes. Thanks for catching that.

>
> >+ }
> > nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
> > array_size = (nr_pages * sizeof(struct page *));
> >
>

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xensource.com/xen-devel


carsten at schiers

Feb 28, 2012, 6:35 AM

Post #54 of 66 (537 views)
Permalink
Re: Load increase after memory upgrade (part2) [In reply to]

Well let me check for a longer period of time, and especially, whether the DomU is still

working (can do that only from at home), but load looks pretty well after applying the

patch to 3.2.8 :-D.

 
BR,

Carsten.
 
-----Ursprüngliche Nachricht-----
An:Jan Beulich <JBeulich [at] suse>;
CC:Konrad Rzeszutek Wilk <konrad [at] darnok>; xen-devel <xen-devel [at] lists>; Carsten Schiers <carsten [at] schiers>; Sander Eikelenboom <linux [at] eikelenboom>;
Von:Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>
Gesendet:Fr 17.02.2012 16:18
Betreff:Re: [Xen-devel] Load increase after memory upgrade (part2)
On Thu, Feb 16, 2012 at 08:56:53AM +0000, Jan Beulich wrote:
> >>> On 15.02.12 at 20:28, Konrad Rzeszutek Wilk <konrad.wilk [at] oracle> wrote:
> >@@ -1550,7 +1552,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> > struct page **pages;
> > unsigned int nr_pages, array_size, i;
> > gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
> >-
> >+gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
> >+if (xen_pv_domain()) {
> >+if (dma_mask == (__GFP_DMA | __GFP_DMA32))
>
> I didn't spot where you force this normally invalid combination, without
> which the change won't affect vmalloc32() in a 32-bit kernel.
>
> >+gfp_mask &= (__GFP_DMA | __GFP_DMA32);
>
> gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);
>
> Jan

Duh!
Good eyes. Thanks for catching that.

>
> >+}
> > nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
> > array_size = (nr_pages * sizeof(struct page *));
> >
>

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xensource.com/xen-devel


carsten at schiers

Feb 29, 2012, 4:10 AM

Post #55 of 66 (538 views)
Permalink
Re: Load increase after memory upgrade (part2) [In reply to]

Great news: it works and load is back to normal. In the attached graph you can see the peak

in blue (compilation of the patched 3.2.8 Kernel) and then after 16.00 the going life of the

video DomU. We are below an avaerage of 7% usage (figures are in Permille).


Thanks so much. Is that already "the final patch"?

 
BR, Carsten.

 

 
-----Ursprüngliche Nachricht-----
An:Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>;
CC:Sander Eikelenboom <linux [at] eikelenboom>; xen-devel <xen-devel [at] lists>; Jan Beulich <jbeulich [at] suse>; Konrad Rzeszutek Wilk <konrad [at] darnok>;
Von:Carsten Schiers <carsten [at] schiers>
Gesendet:Di 28.02.2012 15:39
Betreff:Re: [Xen-devel] Load increase after memory upgrade (part2)
Anlage:inline.txt


Well let me check for a longer period of time, and especially, whether the DomU is still

working (can do that only from at home), but load looks pretty well after applying the

patch to 3.2.8 :-D.

 
BR,

Carsten.
 
-----Ursprüngliche Nachricht-----
An:Jan Beulich <JBeulich [at] suse>;
CC:Konrad Rzeszutek Wilk <konrad [at] darnok>; xen-devel <xen-devel [at] lists>; Carsten Schiers <carsten [at] schiers>; Sander Eikelenboom <linux [at] eikelenboom>;
Von:Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>
Gesendet:Fr 17.02.2012 16:18
Betreff:Re: [Xen-devel] Load increase after memory upgrade (part2)
On Thu, Feb 16, 2012 at 08:56:53AM +0000, Jan Beulich wrote:
> >>> On 15.02.12 at 20:28, Konrad Rzeszutek Wilk <konrad.wilk [at] oracle> wrote:
> >@@ -1550,7 +1552,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> > struct page **pages;
> > unsigned int nr_pages, array_size, i;
> > gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
> >-
> >+gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
> >+if (xen_pv_domain()) {
> >+if (dma_mask == (__GFP_DMA | __GFP_DMA32))
>
> I didn't spot where you force this normally invalid combination, without
> which the change won't affect vmalloc32() in a 32-bit kernel.
>
> >+gfp_mask &= (__GFP_DMA | __GFP_DMA32);
>
> gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);
>
> Jan

Duh!
Good eyes. Thanks for catching that.

>
> >+}
> > nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
> > array_size = (nr_pages * sizeof(struct page *));
> >
>

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xensource.com/xen-devel


carsten at schiers

Feb 29, 2012, 4:56 AM

Post #56 of 66 (529 views)
Permalink
Re: Load increase after memory upgrade (part2) [In reply to]

I am very sorry. I accidently started the DomU with the wrong config file, thus it's clear why there is no difference

between the two. And unfortunately, the DomU with the correct config file is having a BUG:

 


[ 14.674883] BUG: unable to handle kernel paging request at ffffc7fffffff000
[ 14.674910] IP: [<ffffffff811b4c0b>] swiotlb_bounce+0x2e/0x31
[ 14.674930] PGD 0
[ 14.674940] Oops: 0002 [#1] SMP
[ 14.674952] CPU 0
[ 14.674957] Modules linked in: nfsd exportfs nfs lockd fscache auth_rpcgss nfs_acl sunrpc tda10023 budget_av evdev saa7146_vv videodev v4l2_compat_ioctl32 videobuf_dma_sg videobuf_core budget_core snd_pcm dvb_core snd_timer saa7146 snd ttpci_eeprom soundcore snd_page_alloc i2c_core pcspkr ext3 jbd mbcache xen_netfront xen_blkfront
[ 14.675057]
[ 14.675065] Pid: 0, comm: swapper/0 Not tainted 3.2.8-amd64 #1
[ 14.675079] RIP: e030:[<ffffffff811b4c0b>] [<ffffffff811b4c0b>] swiotlb_bounce+0x2e/0x31
[ 14.675097] RSP: e02b:ffff880013fabe58 EFLAGS: 00010202
[ 14.675106] RAX: ffff880012800000 RBX: 0000000000000001 RCX: 0000000000001000
[ 14.675116] RDX: 0000000000001000 RSI: ffff880012800000 RDI: ffffc7fffffff000
[ 14.675126] RBP: 0000000000000002 R08: ffffc7fffffff000 R09: ffff880013f98000
[ 14.675137] R10: 0000000000000001 R11: ffff880003376000 R12: ffff8800032c5090
[ 14.675147] R13: 0000000000000149 R14: ffff8800033e0000 R15: ffffffff81601fd8
[ 14.675163] FS: 00007f3ff9893700(0000) GS:ffff880013fa8000(0000) knlGS:0000000000000000
[ 14.675175] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 14.675184] CR2: ffffc7fffffff000 CR3: 0000000012683000 CR4: 0000000000000660
[ 14.675195] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 14.675205] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 14.675216] Process swapper/0 (pid: 0, threadinfo ffffffff81600000, task ffffffff8160d020)
[ 14.675227] Stack:
[ 14.675232] ffffffff81211826 ffff880002eda000 0000000000000000 ffffc90000408000
[ 14.675251] 00000000000b0150 0000000000000006 ffffffffa013ec4a ffffffff810946cd
[ 14.675270] ffffffff81099203 ffff880003376000 0000000000000000 ffff880002eda4b0
[ 14.675289] Call Trace:
[ 14.675295] <IRQ>
[ 14.675307] [<ffffffff81211826>] ? xen_swiotlb_sync_sg_for_cpu+0x2e/0x47
[ 14.675322] [<ffffffffa013ec4a>] ? vpeirq+0x7f/0x198 [budget_core]
[ 14.675337] [<ffffffff810946cd>] ? handle_irq_event_percpu+0x166/0x184
[ 14.675350] [<ffffffff81099203>] ? __rcu_process_callbacks+0x71/0x2f8
[ 14.675364] [<ffffffff8104d175>] ? tasklet_action+0x76/0xc5
[ 14.675376] [<ffffffff8120a9ac>] ? eoi_pirq+0x5b/0x77
[ 14.675388] [<ffffffff8104cbc6>] ? __do_softirq+0xc4/0x1a0
[ 14.675400] [<ffffffff8120a022>] ? __xen_evtchn_do_upcall+0x1c7/0x205
[ 14.675412] [<ffffffff8134b06c>] ? call_softirq+0x1c/0x30
[ 14.675425] [<ffffffff8100fa47>] ? do_softirq+0x3f/0x79
[ 14.675436] [<ffffffff8104c996>] ? irq_exit+0x44/0xb5
[ 14.675452] [<ffffffff8120b032>] ? xen_evtchn_do_upcall+0x27/0x32
[ 14.675464] [<ffffffff8134b0be>] ? xen_do_hypervisor_callback+0x1e/0x30
[ 14.675473] <EOI>

 
Complete log is attached.

 
BR, Carsten.
 
-----Ursprüngliche Nachricht-----
An:Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>;
CC:Konrad Rzeszutek Wilk <konrad [at] darnok>; xen-devel <xen-devel [at] lists>; Jan Beulich <jbeulich [at] suse>; Sander Eikelenboom <linux [at] eikelenboom>;
Von:Carsten Schiers <carsten [at] schiers>
Gesendet:Mi 29.02.2012 13:16
Betreff:Re: [Xen-devel] Load increase after memory upgrade (part2)
Anlage:inline.txt


Great news: it works and load is back to normal. In the attached graph you can see the peak

in blue (compilation of the patched 3.2.8 Kernel) and then after 16.00 the going life of the

video DomU. We are below an avaerage of 7% usage (figures are in Permille).


Thanks so much. Is that already "the final patch"?

 
BR, Carsten.

 

 
-----Ursprüngliche Nachricht-----
An:Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>;
CC:Sander Eikelenboom <linux [at] eikelenboom>; xen-devel <xen-devel [at] lists>; Jan Beulich <jbeulich [at] suse>; Konrad Rzeszutek Wilk <konrad [at] darnok>;
Von:Carsten Schiers <carsten [at] schiers>
Gesendet:Di 28.02.2012 15:39
Betreff:Re: [Xen-devel] Load increase after memory upgrade (part2)
Anlage:inline.txt


Well let me check for a longer period of time, and especially, whether the DomU is still

working (can do that only from at home), but load looks pretty well after applying the

patch to 3.2.8 :-D.

 
BR,

Carsten.
 
-----Ursprüngliche Nachricht-----
An:Jan Beulich <JBeulich [at] suse>;
CC:Konrad Rzeszutek Wilk <konrad [at] darnok>; xen-devel <xen-devel [at] lists>; Carsten Schiers <carsten [at] schiers>; Sander Eikelenboom <linux [at] eikelenboom>;
Von:Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>
Gesendet:Fr 17.02.2012 16:18
Betreff:Re: [Xen-devel] Load increase after memory upgrade (part2)
On Thu, Feb 16, 2012 at 08:56:53AM +0000, Jan Beulich wrote:
> >>> On 15.02.12 at 20:28, Konrad Rzeszutek Wilk <konrad.wilk [at] oracle> wrote:
> >@@ -1550,7 +1552,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> > struct page **pages;
> > unsigned int nr_pages, array_size, i;
> > gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
> >-
> >+gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
> >+if (xen_pv_domain()) {
> >+if (dma_mask == (__GFP_DMA | __GFP_DMA32))
>
> I didn't spot where you force this normally invalid combination, without
> which the change won't affect vmalloc32() in a 32-bit kernel.
>
> >+gfp_mask &= (__GFP_DMA | __GFP_DMA32);
>
> gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);
>
> Jan

Duh!
Good eyes. Thanks for catching that.

>
> >+}
> > nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
> > array_size = (nr_pages * sizeof(struct page *));
> >
>

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xensource.com/xen-devel



 
Attachments: debug.log (20.9 KB)


carsten at schiers

May 11, 2012, 2:39 AM

Post #57 of 66 (495 views)
Permalink
Re: Load increase after memory upgrade (part2) [In reply to]

Hi Konrad,

 
don't want to be pushy, as I have no real issue. I simply use the Xenified kernel or take the double load.

But I think this mistery is still open. My last status was that the latest patch you produced resulted in a BUG,

so we still have not checked whether our theory is correct.

 
BR,

Carsten.
 
-----Ursprüngliche Nachricht-----
Von:Carsten Schiers <carsten [at] schiers>
Gesendet:Mi 29.02.2012 14:01
Betreff:Re: [Xen-devel] Load increase after memory upgrade (part2)
Anlage:debug.log, inline.txt
An:Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>;
CC:Sander Eikelenboom <linux [at] eikelenboom>; xen-devel <xen-devel [at] lists>; Jan Beulich <jbeulich [at] suse>; Konrad Rzeszutek Wilk <konrad [at] darnok>;


I am very sorry. I accidently started the DomU with the wrong config file, thus it's clear why there is no difference

between the two. And unfortunately, the DomU with the correct config file is having a BUG:

 


[ 14.674883] BUG: unable to handle kernel paging request at ffffc7fffffff000 [ 14.674910] IP: [<ffffffff811b4c0b>] swiotlb_bounce+0x2e/0x31 [ 14.674930] PGD 0 [ 14.674940] Oops: 0002 [#1] SMP [ 14.674952] CPU 0 [ 14.674957] Modules linked in: nfsd exportfs nfs lockd fscache auth_rpcgss nfs_acl sunrpc tda10023 budget_av evdev saa7146_vv videodev v4l2_compat_ioctl32 videobuf_dma_sg videobuf_core budget_core snd_pcm dvb_core snd_timer saa7146 snd ttpci_eeprom soundcore snd_page_alloc i2c_core pcspkr ext3 jbd mbcache xen_netfront xen_blkfront [ 14.675057] [ 14.675065] Pid: 0, comm: swapper/0 Not tainted 3.2.8-amd64 #1 [ 14.675079] RIP: e030:[<ffffffff811b4c0b>] [<ffffffff811b4c0b>] swiotlb_bounce+0x2e/0x31 [ 14.675097] RSP: e02b:ffff880013fabe58 EFLAGS: 00010202 [ 14.675106] RAX: ffff880012800000 RBX: 0000000000000001 RCX: 0000000000001000 [ 14.675116] RDX: 0000000000001000 RSI: ffff880012800000 RDI: ffffc7fffffff000 [ 14.675126] RBP: 0000000000000002 R08: ffffc7fffffff000 R09: ffff880013f98000 [ 14.675137] R10: 0000000000000001 R11: ffff880003376000 R12: ffff8800032c5090 [ 14.675147] R13: 0000000000000149 R14: ffff8800033e0000 R15: ffffffff81601fd8 [ 14.675163] FS: 00007f3ff9893700(0000) GS:ffff880013fa8000(0000) knlGS:0000000000000000 [ 14.675175] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b [ 14.675184] CR2: ffffc7fffffff000 CR3: 0000000012683000 CR4: 0000000000000660 [ 14.675195] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 14.675205] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 14.675216] Process swapper/0 (pid: 0, threadinfo ffffffff81600000, task ffffffff8160d020) [ 14.675227] Stack: [ 14.675232] ffffffff81211826 ffff880002eda000 0000000000000000 ffffc90000408000 [ 14.675251] 00000000000b0150 0000000000000006 ffffffffa013ec4a ffffffff810946cd [ 14.675270] ffffffff81099203 ffff880003376000 0000000000000000 ffff880002eda4b0 [ 14.675289] Call Trace: [ 14.675295] <IRQ> [ 14.675307] [<ffffffff81211826>] ? xen_swiotlb_sync_sg_for_cpu+0x2e/0x47 [ 14.675322] [<ffffffffa013ec4a>] ? vpeirq+0x7f/0x198 [budget_core] [ 14.675337] [<ffffffff810946cd>] ? handle_irq_event_percpu+0x166/0x184 [ 14.675350] [<ffffffff81099203>] ? __rcu_process_callbacks+0x71/0x2f8 [ 14.675364] [<ffffffff8104d175>] ? tasklet_action+0x76/0xc5 [ 14.675376] [<ffffffff8120a9ac>] ? eoi_pirq+0x5b/0x77 [ 14.675388] [<ffffffff8104cbc6>] ? __do_softirq+0xc4/0x1a0 [ 14.675400] [<ffffffff8120a022>] ? __xen_evtchn_do_upcall+0x1c7/0x205 [ 14.675412] [<ffffffff8134b06c>] ? call_softirq+0x1c/0x30 [ 14.675425] [<ffffffff8100fa47>] ? do_softirq+0x3f/0x79 [ 14.675436] [<ffffffff8104c996>] ? irq_exit+0x44/0xb5 [ 14.675452] [<ffffffff8120b032>] ? xen_evtchn_do_upcall+0x27/0x32 [ 14.675464] [<ffffffff8134b0be>] ? xen_do_hypervisor_callback+0x1e/0x30 [ 14.675473] <EOI>

 
Complete log is attached.

 
BR, Carsten.
 
-----Ursprüngliche Nachricht-----
An:Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>;
CC:Konrad Rzeszutek Wilk <konrad [at] darnok>; xen-devel <xen-devel [at] lists>; Jan Beulich <jbeulich [at] suse>; Sander Eikelenboom <linux [at] eikelenboom>;
Von:Carsten Schiers <carsten [at] schiers>
Gesendet:Mi 29.02.2012 13:16
Betreff:Re: [Xen-devel] Load increase after memory upgrade (part2)
Anlage:inline.txt


Great news: it works and load is back to normal. In the attached graph you can see the peak

in blue (compilation of the patched 3.2.8 Kernel) and then after 16.00 the going life of the

video DomU. We are below an avaerage of 7% usage (figures are in Permille).


Thanks so much. Is that already "the final patch"?

 
BR, Carsten.

 

 
-----Ursprüngliche Nachricht-----
An:Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>;
CC:Sander Eikelenboom <linux [at] eikelenboom>; xen-devel <xen-devel [at] lists>; Jan Beulich <jbeulich [at] suse>; Konrad Rzeszutek Wilk <konrad [at] darnok>;
Von:Carsten Schiers <carsten [at] schiers>
Gesendet:Di 28.02.2012 15:39
Betreff:Re: [Xen-devel] Load increase after memory upgrade (part2)
Anlage:inline.txt


Well let me check for a longer period of time, and especially, whether the DomU is still

working (can do that only from at home), but load looks pretty well after applying the

patch to 3.2.8 :-D.

 
BR,

Carsten.
 
-----Ursprüngliche Nachricht-----
An:Jan Beulich <JBeulich [at] suse>;
CC:Konrad Rzeszutek Wilk <konrad [at] darnok>; xen-devel <xen-devel [at] lists>; Carsten Schiers <carsten [at] schiers>; Sander Eikelenboom <linux [at] eikelenboom>;
Von:Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>
Gesendet:Fr 17.02.2012 16:18
Betreff:Re: [Xen-devel] Load increase after memory upgrade (part2)
On Thu, Feb 16, 2012 at 08:56:53AM +0000, Jan Beulich wrote:
> >>> On 15.02.12 at 20:28, Konrad Rzeszutek Wilk <konrad.wilk [at] oracle> wrote:
> >@@ -1550,7 +1552,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> > struct page **pages;
> > unsigned int nr_pages, array_size, i;
> > gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
> >-
> >+gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
> >+if (xen_pv_domain()) {
> >+if (dma_mask == (__GFP_DMA | __GFP_DMA32))
>
> I didn't spot where you force this normally invalid combination, without
> which the change won't affect vmalloc32() in a 32-bit kernel.
>
> >+gfp_mask &= (__GFP_DMA | __GFP_DMA32);
>
> gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);
>
> Jan

Duh!
Good eyes. Thanks for catching that.

>
> >+}
> > nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
> > array_size = (nr_pages * sizeof(struct page *));
> >
>

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xensource.com/xen-devel



 
--------------------------------
E-Mail ist virenfrei.
Von AVG überprüft - www.avg.de
Version: 2012.0.2127 / Virendatenbank: 2411/4932 - Ausgabedatum: 12.04.2012


konrad.wilk at oracle

May 11, 2012, 12:41 PM

Post #58 of 66 (497 views)
Permalink
Re: Load increase after memory upgrade (part2) [In reply to]

On Fri, May 11, 2012 at 11:39:08AM +0200, Carsten Schiers wrote:
> Hi Konrad,
>
>
> don't want to be pushy, as I have no real issue. I simply use the Xenified kernel or take the double load.
>
> But I think this mistery is still open. My last status was that the latest patch you produced resulted in a BUG,

Yes, that is right. Thank you for reminding me.
>
> so we still have not checked whether our theory is correct.

No we haven't. And I should be have no trouble reproducing this. I can just write
a tiny module that allocates vmalloc_32().

But your timming sucks - I am going on a week vacation next week :-(

Ah, if there was just a cloning machine - I could stick myself in it,
and Baseline_0 goes on vacation, while Clone_1 goes on working. Then
git merge Baseline_0 and Clone_1 in a week and fixup the merge conflicts
and continue on. Sigh.

Can I ask you to be patient with me once more and ping me in a week - when
I am back from vacation and my brain is fresh to work on this?

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel


konrad.wilk at oracle

Jun 13, 2012, 9:55 AM

Post #59 of 66 (482 views)
Permalink
Re: Load increase after memory upgrade (part2) [In reply to]

On Fri, May 11, 2012 at 03:41:38PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, May 11, 2012 at 11:39:08AM +0200, Carsten Schiers wrote:
> > Hi Konrad,
> >
> >
> > don't want to be pushy, as I have no real issue. I simply use the Xenified kernel or take the double load.
> >
> > But I think this mistery is still open. My last status was that the latest patch you produced resulted in a BUG,
>
> Yes, that is right. Thank you for reminding me.
> >
> > so we still have not checked whether our theory is correct.
>
> No we haven't. And I should be have no trouble reproducing this. I can just write
> a tiny module that allocates vmalloc_32().

Done. Found some bugs.. and here is anew version. Can you please
try it out? It has the #define DEBUG 1 set so it should print a lot of
stuff when the DVB module loads. If it crashes please send me the full log.

Thanks.
From 5afb4ab1fb3d2b059fe1a6db93ab65cb76f43b8a Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>
Date: Thu, 31 May 2012 14:21:04 -0400
Subject: [PATCH] xen/vmalloc_32: Use xen_exchange_.. when GFP flags are DMA.
[v3]

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>
---
arch/x86/xen/mmu.c | 187 +++++++++++++++++++++++++++++++++++++++++++++++-
include/xen/xen-ops.h | 2 +
mm/vmalloc.c | 18 +++++-
3 files changed, 202 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 3a73785..960d206 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -47,6 +47,7 @@
#include <linux/gfp.h>
#include <linux/memblock.h>
#include <linux/seq_file.h>
+#include <linux/slab.h>

#include <trace/events/xen.h>

@@ -2051,6 +2052,7 @@ void __init xen_init_mmu_ops(void)
/* Protected by xen_reservation_lock. */
#define MAX_CONTIG_ORDER 9 /* 2MB */
static unsigned long discontig_frames[1<<MAX_CONTIG_ORDER];
+static unsigned long limited_frames[1<<MAX_CONTIG_ORDER];

#define VOID_PTE (mfn_pte(0, __pgprot(0)))
static void xen_zap_pfn_range(unsigned long vaddr, unsigned int order,
@@ -2075,6 +2077,42 @@ static void xen_zap_pfn_range(unsigned long vaddr, unsigned int order,
}
xen_mc_issue(0);
}
+static int xen_zap_page_range(struct page *pages, unsigned int order,
+ unsigned long *in_frames,
+ unsigned long *out_frames,
+ void *limit_bitmap)
+{
+ int i, n = 0;
+ struct multicall_space mcs;
+ struct page *page;
+
+ xen_mc_batch();
+ for (i = 0; i < (1UL<<order); i++) {
+ if (!test_bit(i, limit_bitmap))
+ continue;
+
+ page = &pages[i];
+ mcs = __xen_mc_entry(0);
+#define DEBUG 1
+ if (in_frames) {
+#ifdef DEBUG
+ printk(KERN_INFO "%s:%d 0x%lx(pfn) 0x%lx (mfn) 0x%lx(vaddr)\n",
+ __func__, i, page_to_pfn(page),
+ pfn_to_mfn(page_to_pfn(page)), page_address(page));
+#endif
+ in_frames[i] = pfn_to_mfn(page_to_pfn(page));
+ }
+ MULTI_update_va_mapping(mcs.mc, (unsigned long)page_address(page), VOID_PTE, 0);
+ set_phys_to_machine(page_to_pfn(page), INVALID_P2M_ENTRY);
+
+ if (out_frames)
+ out_frames[i] = page_to_pfn(page);
+ ++n;
+
+ }
+ xen_mc_issue(0);
+ return n;
+}

/*
* Update the pfn-to-mfn mappings for a virtual address range, either to
@@ -2118,6 +2156,53 @@ static void xen_remap_exchanged_ptes(unsigned long vaddr, int order,

xen_mc_issue(0);
}
+static void xen_remap_exchanged_pages(struct page *pages, int order,
+ unsigned long *mfns,
+ unsigned long first_mfn, /* in_frame if we failed*/
+ void *limit_map)
+{
+ unsigned i, limit;
+ unsigned long mfn;
+ struct page *page;
+
+ xen_mc_batch();
+
+ limit = 1ULL << order;
+ for (i = 0; i < limit; i++) {
+ struct multicall_space mcs;
+ unsigned flags;
+
+ if (!test_bit(i, limit_map))
+ continue;
+
+ page = &pages[i];
+ mcs = __xen_mc_entry(0);
+ if (mfns)
+ mfn = mfns[i];
+ else
+ mfn = first_mfn + i;
+
+ if (i < (limit - 1))
+ flags = 0;
+ else {
+ if (order == 0)
+ flags = UVMF_INVLPG | UVMF_ALL;
+ else
+ flags = UVMF_TLB_FLUSH | UVMF_ALL;
+ }
+#ifdef DEBUG
+ printk(KERN_INFO "%s (%d) pfn:0x%lx, pfn: 0x%lx vaddr: 0x%lx\n",
+ __func__, i, page_to_pfn(page), mfn, page_address(page));
+#endif
+ MULTI_update_va_mapping(mcs.mc, (unsigned long)page_address(page),
+ mfn_pte(mfn, PAGE_KERNEL), flags);
+
+ set_phys_to_machine(page_to_pfn(page), mfn);
+ }
+
+ xen_mc_issue(0);
+}
+

/*
* Perform the hypercall to exchange a region of our pfns to point to
@@ -2136,7 +2221,9 @@ static int xen_exchange_memory(unsigned long extents_in, unsigned int order_in,
{
long rc;
int success;
-
+#ifdef DEBUG
+ int i;
+#endif
struct xen_memory_exchange exchange = {
.in = {
.nr_extents = extents_in,
@@ -2157,7 +2244,11 @@ static int xen_exchange_memory(unsigned long extents_in, unsigned int order_in,

rc = HYPERVISOR_memory_op(XENMEM_exchange, &exchange);
success = (exchange.nr_exchanged == extents_in);
-
+#ifdef DEBUG
+ for (i = 0; i < exchange.nr_exchanged; i++) {
+ printk(KERN_INFO "%s 0x%lx (mfn) <-> 0x%lx (mfn)\n", __func__,pfns_in[i], mfns_out[i]);
+ }
+#endif
BUG_ON(!success && ((exchange.nr_exchanged != 0) || (rc == 0)));
BUG_ON(success && (rc != 0));

@@ -2231,8 +2322,8 @@ void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order)
xen_zap_pfn_range(vstart, order, NULL, out_frames);

/* 3. Do the exchange for non-contiguous MFNs. */
- success = xen_exchange_memory(1, order, &in_frame, 1UL << order,
- 0, out_frames, 0);
+ success = xen_exchange_memory(1, order, &in_frame,
+ 1UL << order, 0, out_frames, 0);

/* 4. Map new pages in place of old pages. */
if (success)
@@ -2244,6 +2335,94 @@ void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order)
}
EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);

+int xen_limit_pages_to_max_mfn(struct page *pages, unsigned int order,
+ unsigned int address_bits)
+{
+ unsigned long *in_frames = discontig_frames, *out_frames = limited_frames;
+ unsigned long flags;
+ struct page *page;
+ int success;
+ int i, n = 0;
+ unsigned long _limit_map;
+ unsigned long *limit_map;
+
+ if (xen_feature(XENFEAT_auto_translated_physmap))
+ return 0;
+
+ if (unlikely(order > MAX_CONTIG_ORDER))
+ return -ENOMEM;
+
+ if (BITS_PER_LONG >> order) {
+ limit_map = kzalloc(BITS_TO_LONGS(1U << order) *
+ sizeof(*limit_map), GFP_KERNEL);
+ if (unlikely(!limit_map))
+ return -ENOMEM;
+ } else
+ limit_map = &_limit_map;
+
+ /* 0. Construct our per page bitmap lookup. */
+
+ if (address_bits && (address_bits < PAGE_SHIFT))
+ return -EINVAL;
+
+ if (order)
+ bitmap_zero(limit_map, 1U << order);
+ else
+ __set_bit(0, limit_map);
+
+ /* 1. Clear the pages */
+ for (i = 0; i < (1ULL << order); i++) {
+ void *vaddr;
+ page = &pages[i];
+
+ vaddr = page_address(page);
+#ifdef DEBUG
+ printk(KERN_INFO "%s: page: %p vaddr: %p 0x%lx(mfn) 0x%lx(pfn)\n", __func__, page, vaddr, virt_to_mfn(vaddr), mfn_to_pfn(virt_to_mfn(vaddr)));
+#endif
+ if (address_bits) {
+ if (!(virt_to_mfn(vaddr) >> (address_bits - PAGE_SHIFT)))
+ continue;
+ __set_bit(i, limit_map);
+ }
+ if (!PageHighMem(page))
+ memset(vaddr, 0, PAGE_SIZE);
+ else {
+ memset(kmap(page), 0, PAGE_SIZE);
+ kunmap(page);
+ ++n;
+ }
+ }
+ /* Check to see if we actually have to do any work. */
+ if (bitmap_empty(limit_map, 1U << order)) {
+ if (limit_map != &_limit_map)
+ kfree(limit_map);
+ return 0;
+ }
+ if (n)
+ kmap_flush_unused();
+
+ spin_lock_irqsave(&xen_reservation_lock, flags);
+
+ /* 2. Zap current PTEs. */
+ n = xen_zap_page_range(pages, order, in_frames, NULL /*out_frames */, limit_map);
+
+ /* 3. Do the exchange for non-contiguous MFNs. */
+ success = xen_exchange_memory(n, 0 /* this is always called per page */, in_frames,
+ n, 0, out_frames, address_bits);
+
+ /* 4. Map new pages in place of old pages. */
+ if (success)
+ xen_remap_exchanged_pages(pages, order, out_frames, 0, limit_map);
+ else
+ xen_remap_exchanged_pages(pages, order, NULL, *in_frames, limit_map);
+
+ spin_unlock_irqrestore(&xen_reservation_lock, flags);
+ if (limit_map != &_limit_map)
+ kfree(limit_map);
+
+ return success ? 0 : -ENOMEM;
+}
+EXPORT_SYMBOL_GPL(xen_limit_pages_to_max_mfn);
#ifdef CONFIG_XEN_PVHVM
static void xen_hvm_exit_mmap(struct mm_struct *mm)
{
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 6a198e4..2f8709f 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -29,4 +29,6 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
unsigned long mfn, int nr,
pgprot_t prot, unsigned domid);

+int xen_limit_pages_to_max_mfn(struct page *pages, unsigned int order,
+ unsigned int address_bits);
#endif /* INCLUDE_XEN_OPS_H */
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 2aad499..194af07 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -31,6 +31,8 @@
#include <asm/tlbflush.h>
#include <asm/shmparam.h>

+#include <xen/xen.h>
+#include <xen/xen-ops.h>
/*** Page table manipulation functions ***/

static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end)
@@ -1576,7 +1578,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
struct page **pages;
unsigned int nr_pages, array_size, i;
gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
-
+ gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
+ if (xen_pv_domain()) {
+ if (dma_mask == (__GFP_DMA | __GFP_DMA32))
+ gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);
+ }
nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
array_size = (nr_pages * sizeof(struct page *));

@@ -1612,6 +1618,16 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
goto fail;
}
area->pages[i] = page;
+ if (xen_pv_domain()) {
+ if (dma_mask) {
+ if (xen_limit_pages_to_max_mfn(page, 0, 32)) {
+ area->nr_pages = i + 1;
+ goto fail;
+ }
+ if (gfp_mask & __GFP_ZERO)
+ clear_highpage(page);
+ }
+ }
}

if (map_vm_area(area, prot, &pages))
--
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel


JBeulich at suse

Jun 14, 2012, 12:07 AM

Post #60 of 66 (481 views)
Permalink
Re: Load increase after memory upgrade (part2) [In reply to]

>>> On 13.06.12 at 18:55, Konrad Rzeszutek Wilk <konrad.wilk [at] oracle> wrote:
> @@ -1576,7 +1578,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> struct page **pages;
> unsigned int nr_pages, array_size, i;
> gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
> -
> + gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
> + if (xen_pv_domain()) {
> + if (dma_mask == (__GFP_DMA | __GFP_DMA32))

As said in an earlier reply - without having any place that would
ever set both flags at once, this whole conditional is meaningless.
In our code - which I suppose is where you cloned this from - we
set GFP_VMALLOC32 to such a value for 32-bit kernels (which
otherwise would merely use GFP_KERNEL, and hence not trigger
the code calling xen_limit_pages_to_max_mfn()). I don't recall
though whether Carsten's problem was on a 32- or 64-bit kernel.

Jan

> + gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);
> + }
> nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
> array_size = (nr_pages * sizeof(struct page *));
>



_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel


dvrabel at cantab

Jun 14, 2012, 1:38 AM

Post #61 of 66 (483 views)
Permalink
Re: Load increase after memory upgrade (part2) [In reply to]

On 13/06/12 17:55, Konrad Rzeszutek Wilk wrote:
>
> + /* 3. Do the exchange for non-contiguous MFNs. */
> + success = xen_exchange_memory(n, 0 /* this is always called per page */, in_frames,
> + n, 0, out_frames, address_bits);

vmalloc() does not require physically contiguous MFNs.

David

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel


konrad.wilk at oracle

Jun 14, 2012, 11:31 AM

Post #62 of 66 (481 views)
Permalink
Re: Load increase after memory upgrade (part2) [In reply to]

On Thu, Jun 14, 2012 at 09:38:31AM +0100, David Vrabel wrote:
> On 13/06/12 17:55, Konrad Rzeszutek Wilk wrote:
> >
> > + /* 3. Do the exchange for non-contiguous MFNs. */
> > + success = xen_exchange_memory(n, 0 /* this is always called per page */, in_frames,
> > + n, 0, out_frames, address_bits);
>
> vmalloc() does not require physically contiguous MFNs.

<nods> It doesn't matter that much in this context as the vmalloc
calls this per-page - so it is only one page that is swizzled.

>
> David

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel


konrad.wilk at oracle

Jun 14, 2012, 11:33 AM

Post #63 of 66 (483 views)
Permalink
Re: Load increase after memory upgrade (part2) [In reply to]

On Thu, Jun 14, 2012 at 08:07:55AM +0100, Jan Beulich wrote:
> >>> On 13.06.12 at 18:55, Konrad Rzeszutek Wilk <konrad.wilk [at] oracle> wrote:
> > @@ -1576,7 +1578,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> > struct page **pages;
> > unsigned int nr_pages, array_size, i;
> > gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
> > -
> > + gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
> > + if (xen_pv_domain()) {
> > + if (dma_mask == (__GFP_DMA | __GFP_DMA32))
>
> As said in an earlier reply - without having any place that would
> ever set both flags at once, this whole conditional is meaningless.
> In our code - which I suppose is where you cloned this from - we

Yup.
> set GFP_VMALLOC32 to such a value for 32-bit kernels (which
> otherwise would merely use GFP_KERNEL, and hence not trigger

Ah, let me double check. Thanks for looking out for this.

> the code calling xen_limit_pages_to_max_mfn()). I don't recall
> though whether Carsten's problem was on a 32- or 64-bit kernel.
>
> Jan
>
> > + gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);
> > + }
> > nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
> > array_size = (nr_pages * sizeof(struct page *));
> >
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel [at] lists
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel


carsten at schiers

Jun 14, 2012, 11:40 AM

Post #64 of 66 (484 views)
Permalink
Re: Load increase after memory upgrade (part2) [In reply to]

Konrad, against which kernel version did you produce this patch? It will not succeed
with 3.4.2 at least, will look up some older version now...

-----Ursprngliche Nachricht-----
Von: xen-devel-bounces [at] lists [mailto:xen-devel-bounces [at] lists] Im Auftrag von Konrad Rzeszutek Wilk
Gesendet: Mittwoch, 13. Juni 2012 18:55
An: Carsten Schiers
Cc: Konrad Rzeszutek Wilk; xen-devel; Jan Beulich; Sander Eikelenboom
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

On Fri, May 11, 2012 at 03:41:38PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, May 11, 2012 at 11:39:08AM +0200, Carsten Schiers wrote:
> > Hi Konrad,
> >
> >
> > don't want to be pushy, as I have no real issue. I simply use the Xenified kernel or take the double load.
> >
> > But I think this mistery is still open. My last status was that the
> > latest patch you produced resulted in a BUG,
>
> Yes, that is right. Thank you for reminding me.
> >
> > so we still have not checked whether our theory is correct.
>
> No we haven't. And I should be have no trouble reproducing this. I can
> just write a tiny module that allocates vmalloc_32().

Done. Found some bugs.. and here is anew version. Can you please try it out? It has the #define DEBUG 1 set so it should print a lot of stuff when the DVB module loads. If it crashes please send me the full log.

Thanks.
From 5afb4ab1fb3d2b059fe1a6db93ab65cb76f43b8a Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>
Date: Thu, 31 May 2012 14:21:04 -0400
Subject: [PATCH] xen/vmalloc_32: Use xen_exchange_.. when GFP flags are DMA.
[v3]

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>
---
arch/x86/xen/mmu.c | 187 +++++++++++++++++++++++++++++++++++++++++++++++-
include/xen/xen-ops.h | 2 +
mm/vmalloc.c | 18 +++++-
3 files changed, 202 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index 3a73785..960d206 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -47,6 +47,7 @@
#include <linux/gfp.h>
#include <linux/memblock.h>
#include <linux/seq_file.h>
+#include <linux/slab.h>

#include <trace/events/xen.h>

@@ -2051,6 +2052,7 @@ void __init xen_init_mmu_ops(void)
/* Protected by xen_reservation_lock. */ #define MAX_CONTIG_ORDER 9 /* 2MB */ static unsigned long discontig_frames[1<<MAX_CONTIG_ORDER];
+static unsigned long limited_frames[1<<MAX_CONTIG_ORDER];

#define VOID_PTE (mfn_pte(0, __pgprot(0))) static void xen_zap_pfn_range(unsigned long vaddr, unsigned int order, @@ -2075,6 +2077,42 @@ static void xen_zap_pfn_range(unsigned long vaddr, unsigned int order,
}
xen_mc_issue(0);
}
+static int xen_zap_page_range(struct page *pages, unsigned int order,
+ unsigned long *in_frames,
+ unsigned long *out_frames,
+ void *limit_bitmap)
+{
+ int i, n = 0;
+ struct multicall_space mcs;
+ struct page *page;
+
+ xen_mc_batch();
+ for (i = 0; i < (1UL<<order); i++) {
+ if (!test_bit(i, limit_bitmap))
+ continue;
+
+ page = &pages[i];
+ mcs = __xen_mc_entry(0);
+#define DEBUG 1
+ if (in_frames) {
+#ifdef DEBUG
+ printk(KERN_INFO "%s:%d 0x%lx(pfn) 0x%lx (mfn) 0x%lx(vaddr)\n",
+ __func__, i, page_to_pfn(page),
+ pfn_to_mfn(page_to_pfn(page)), page_address(page)); #endif
+ in_frames[i] = pfn_to_mfn(page_to_pfn(page));
+ }
+ MULTI_update_va_mapping(mcs.mc, (unsigned long)page_address(page), VOID_PTE, 0);
+ set_phys_to_machine(page_to_pfn(page), INVALID_P2M_ENTRY);
+
+ if (out_frames)
+ out_frames[i] = page_to_pfn(page);
+ ++n;
+
+ }
+ xen_mc_issue(0);
+ return n;
+}

/*
* Update the pfn-to-mfn mappings for a virtual address range, either to @@ -2118,6 +2156,53 @@ static void xen_remap_exchanged_ptes(unsigned long vaddr, int order,

xen_mc_issue(0);
}
+static void xen_remap_exchanged_pages(struct page *pages, int order,
+ unsigned long *mfns,
+ unsigned long first_mfn, /* in_frame if we failed*/
+ void *limit_map)
+{
+ unsigned i, limit;
+ unsigned long mfn;
+ struct page *page;
+
+ xen_mc_batch();
+
+ limit = 1ULL << order;
+ for (i = 0; i < limit; i++) {
+ struct multicall_space mcs;
+ unsigned flags;
+
+ if (!test_bit(i, limit_map))
+ continue;
+
+ page = &pages[i];
+ mcs = __xen_mc_entry(0);
+ if (mfns)
+ mfn = mfns[i];
+ else
+ mfn = first_mfn + i;
+
+ if (i < (limit - 1))
+ flags = 0;
+ else {
+ if (order == 0)
+ flags = UVMF_INVLPG | UVMF_ALL;
+ else
+ flags = UVMF_TLB_FLUSH | UVMF_ALL;
+ }
+#ifdef DEBUG
+ printk(KERN_INFO "%s (%d) pfn:0x%lx, pfn: 0x%lx vaddr: 0x%lx\n",
+ __func__, i, page_to_pfn(page), mfn, page_address(page)); #endif
+ MULTI_update_va_mapping(mcs.mc, (unsigned long)page_address(page),
+ mfn_pte(mfn, PAGE_KERNEL), flags);
+
+ set_phys_to_machine(page_to_pfn(page), mfn);
+ }
+
+ xen_mc_issue(0);
+}
+

/*
* Perform the hypercall to exchange a region of our pfns to point to @@ -2136,7 +2221,9 @@ static int xen_exchange_memory(unsigned long extents_in, unsigned int order_in, {
long rc;
int success;
-
+#ifdef DEBUG
+ int i;
+#endif
struct xen_memory_exchange exchange = {
.in = {
.nr_extents = extents_in,
@@ -2157,7 +2244,11 @@ static int xen_exchange_memory(unsigned long extents_in, unsigned int order_in,

rc = HYPERVISOR_memory_op(XENMEM_exchange, &exchange);
success = (exchange.nr_exchanged == extents_in);
-
+#ifdef DEBUG
+ for (i = 0; i < exchange.nr_exchanged; i++) {
+ printk(KERN_INFO "%s 0x%lx (mfn) <-> 0x%lx (mfn)\n", __func__,pfns_in[i], mfns_out[i]);
+ }
+#endif
BUG_ON(!success && ((exchange.nr_exchanged != 0) || (rc == 0)));
BUG_ON(success && (rc != 0));

@@ -2231,8 +2322,8 @@ void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order)
xen_zap_pfn_range(vstart, order, NULL, out_frames);

/* 3. Do the exchange for non-contiguous MFNs. */
- success = xen_exchange_memory(1, order, &in_frame, 1UL << order,
- 0, out_frames, 0);
+ success = xen_exchange_memory(1, order, &in_frame,
+ 1UL << order, 0, out_frames, 0);

/* 4. Map new pages in place of old pages. */
if (success)
@@ -2244,6 +2335,94 @@ void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order) } EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);

+int xen_limit_pages_to_max_mfn(struct page *pages, unsigned int order,
+ unsigned int address_bits)
+{
+ unsigned long *in_frames = discontig_frames, *out_frames = limited_frames;
+ unsigned long flags;
+ struct page *page;
+ int success;
+ int i, n = 0;
+ unsigned long _limit_map;
+ unsigned long *limit_map;
+
+ if (xen_feature(XENFEAT_auto_translated_physmap))
+ return 0;
+
+ if (unlikely(order > MAX_CONTIG_ORDER))
+ return -ENOMEM;
+
+ if (BITS_PER_LONG >> order) {
+ limit_map = kzalloc(BITS_TO_LONGS(1U << order) *
+ sizeof(*limit_map), GFP_KERNEL);
+ if (unlikely(!limit_map))
+ return -ENOMEM;
+ } else
+ limit_map = &_limit_map;
+
+ /* 0. Construct our per page bitmap lookup. */
+
+ if (address_bits && (address_bits < PAGE_SHIFT))
+ return -EINVAL;
+
+ if (order)
+ bitmap_zero(limit_map, 1U << order);
+ else
+ __set_bit(0, limit_map);
+
+ /* 1. Clear the pages */
+ for (i = 0; i < (1ULL << order); i++) {
+ void *vaddr;
+ page = &pages[i];
+
+ vaddr = page_address(page);
+#ifdef DEBUG
+ printk(KERN_INFO "%s: page: %p vaddr: %p 0x%lx(mfn) 0x%lx(pfn)\n",
+__func__, page, vaddr, virt_to_mfn(vaddr), mfn_to_pfn(virt_to_mfn(vaddr))); #endif
+ if (address_bits) {
+ if (!(virt_to_mfn(vaddr) >> (address_bits - PAGE_SHIFT)))
+ continue;
+ __set_bit(i, limit_map);
+ }
+ if (!PageHighMem(page))
+ memset(vaddr, 0, PAGE_SIZE);
+ else {
+ memset(kmap(page), 0, PAGE_SIZE);
+ kunmap(page);
+ ++n;
+ }
+ }
+ /* Check to see if we actually have to do any work. */
+ if (bitmap_empty(limit_map, 1U << order)) {
+ if (limit_map != &_limit_map)
+ kfree(limit_map);
+ return 0;
+ }
+ if (n)
+ kmap_flush_unused();
+
+ spin_lock_irqsave(&xen_reservation_lock, flags);
+
+ /* 2. Zap current PTEs. */
+ n = xen_zap_page_range(pages, order, in_frames, NULL /*out_frames */,
+limit_map);
+
+ /* 3. Do the exchange for non-contiguous MFNs. */
+ success = xen_exchange_memory(n, 0 /* this is always called per page */, in_frames,
+ n, 0, out_frames, address_bits);
+
+ /* 4. Map new pages in place of old pages. */
+ if (success)
+ xen_remap_exchanged_pages(pages, order, out_frames, 0, limit_map);
+ else
+ xen_remap_exchanged_pages(pages, order, NULL, *in_frames, limit_map);
+
+ spin_unlock_irqrestore(&xen_reservation_lock, flags);
+ if (limit_map != &_limit_map)
+ kfree(limit_map);
+
+ return success ? 0 : -ENOMEM;
+}
+EXPORT_SYMBOL_GPL(xen_limit_pages_to_max_mfn);
#ifdef CONFIG_XEN_PVHVM
static void xen_hvm_exit_mmap(struct mm_struct *mm) { diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h index 6a198e4..2f8709f 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -29,4 +29,6 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
unsigned long mfn, int nr,
pgprot_t prot, unsigned domid);

+int xen_limit_pages_to_max_mfn(struct page *pages, unsigned int order,
+ unsigned int address_bits);
#endif /* INCLUDE_XEN_OPS_H */
diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 2aad499..194af07 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -31,6 +31,8 @@
#include <asm/tlbflush.h>
#include <asm/shmparam.h>

+#include <xen/xen.h>
+#include <xen/xen-ops.h>
/*** Page table manipulation functions ***/

static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end) @@ -1576,7 +1578,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
struct page **pages;
unsigned int nr_pages, array_size, i;
gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
-
+ gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
+ if (xen_pv_domain()) {
+ if (dma_mask == (__GFP_DMA | __GFP_DMA32))
+ gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);
+ }
nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
array_size = (nr_pages * sizeof(struct page *));

@@ -1612,6 +1618,16 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
goto fail;
}
area->pages[i] = page;
+ if (xen_pv_domain()) {
+ if (dma_mask) {
+ if (xen_limit_pages_to_max_mfn(page, 0, 32)) {
+ area->nr_pages = i + 1;
+ goto fail;
+ }
+ if (gfp_mask & __GFP_ZERO)
+ clear_highpage(page);
+ }
+ }
}

if (map_vm_area(area, prot, &pages))
--
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel

-----
E-Mail ist virenfrei.
Von AVG berprft - www.avg.de
Version: 2012.0.2180 / Virendatenbank: 2433/5067 - Ausgabedatum: 13.06.2012


_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel


carsten at schiers

Jun 14, 2012, 11:43 AM

Post #65 of 66 (484 views)
Permalink
Re: Load increase after memory upgrade (part2) [In reply to]

It's a 64 Bit kernel...

-----Ursprngliche Nachricht-----
Von: Jan Beulich [mailto:JBeulich [at] suse]
Gesendet: Donnerstag, 14. Juni 2012 09:08
An: Konrad Rzeszutek Wilk
Cc: Konrad Rzeszutek Wilk; Sander Eikelenboom; xen-devel; Carsten Schiers
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

>>> On 13.06.12 at 18:55, Konrad Rzeszutek Wilk <konrad.wilk [at] oracle> wrote:
> @@ -1576,7 +1578,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> struct page **pages;
> unsigned int nr_pages, array_size, i;
> gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
> -
> + gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
> + if (xen_pv_domain()) {
> + if (dma_mask == (__GFP_DMA | __GFP_DMA32))

As said in an earlier reply - without having any place that would ever set both flags at once, this whole conditional is meaningless.
In our code - which I suppose is where you cloned this from - we set GFP_VMALLOC32 to such a value for 32-bit kernels (which otherwise would merely use GFP_KERNEL, and hence not trigger the code calling xen_limit_pages_to_max_mfn()). I don't recall though whether Carsten's problem was on a 32- or 64-bit kernel.

Jan

> + gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);
> + }
> nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
> array_size = (nr_pages * sizeof(struct page *));
>



-----
E-Mail ist virenfrei.
Von AVG berprft - www.avg.de
Version: 2012.0.2180 / Virendatenbank: 2433/5069 - Ausgabedatum: 14.06.2012


_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel


carsten at schiers

Jun 14, 2012, 12:16 PM

Post #66 of 66 (482 views)
Permalink
Re: Load increase after memory upgrade (part2) [In reply to]

OK, found the problem in the patch file, baking 3.4.2...BR, Carsten.

-----Ursprngliche Nachricht-----
Von: xen-devel-bounces [at] lists [mailto:xen-devel-bounces [at] lists] Im Auftrag von Carsten Schiers
Gesendet: Donnerstag, 14. Juni 2012 20:40
An: Konrad Rzeszutek Wilk
Cc: Konrad Rzeszutek Wilk; xen-devel; Jan Beulich; Sander Eikelenboom
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

Konrad, against which kernel version did you produce this patch? It will not succeed with 3.4.2 at least, will look up some older version now...

-----Ursprngliche Nachricht-----
Von: xen-devel-bounces [at] lists [mailto:xen-devel-bounces [at] lists] Im Auftrag von Konrad Rzeszutek Wilk
Gesendet: Mittwoch, 13. Juni 2012 18:55
An: Carsten Schiers
Cc: Konrad Rzeszutek Wilk; xen-devel; Jan Beulich; Sander Eikelenboom
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

On Fri, May 11, 2012 at 03:41:38PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, May 11, 2012 at 11:39:08AM +0200, Carsten Schiers wrote:
> > Hi Konrad,
> >
> >
> > don't want to be pushy, as I have no real issue. I simply use the Xenified kernel or take the double load.
> >
> > But I think this mistery is still open. My last status was that the
> > latest patch you produced resulted in a BUG,
>
> Yes, that is right. Thank you for reminding me.
> >
> > so we still have not checked whether our theory is correct.
>
> No we haven't. And I should be have no trouble reproducing this. I can
> just write a tiny module that allocates vmalloc_32().

Done. Found some bugs.. and here is anew version. Can you please try it out? It has the #define DEBUG 1 set so it should print a lot of stuff when the DVB module loads. If it crashes please send me the full log.

Thanks.
From 5afb4ab1fb3d2b059fe1a6db93ab65cb76f43b8a Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>
Date: Thu, 31 May 2012 14:21:04 -0400
Subject: [PATCH] xen/vmalloc_32: Use xen_exchange_.. when GFP flags are DMA.
[v3]

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>
---
arch/x86/xen/mmu.c | 187 +++++++++++++++++++++++++++++++++++++++++++++++-
include/xen/xen-ops.h | 2 +
mm/vmalloc.c | 18 +++++-
3 files changed, 202 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index 3a73785..960d206 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -47,6 +47,7 @@
#include <linux/gfp.h>
#include <linux/memblock.h>
#include <linux/seq_file.h>
+#include <linux/slab.h>

#include <trace/events/xen.h>

@@ -2051,6 +2052,7 @@ void __init xen_init_mmu_ops(void)
/* Protected by xen_reservation_lock. */ #define MAX_CONTIG_ORDER 9 /* 2MB */ static unsigned long discontig_frames[1<<MAX_CONTIG_ORDER];
+static unsigned long limited_frames[1<<MAX_CONTIG_ORDER];

#define VOID_PTE (mfn_pte(0, __pgprot(0))) static void xen_zap_pfn_range(unsigned long vaddr, unsigned int order, @@ -2075,6 +2077,42 @@ static void xen_zap_pfn_range(unsigned long vaddr, unsigned int order,
}
xen_mc_issue(0);
}
+static int xen_zap_page_range(struct page *pages, unsigned int order,
+ unsigned long *in_frames,
+ unsigned long *out_frames,
+ void *limit_bitmap)
+{
+ int i, n = 0;
+ struct multicall_space mcs;
+ struct page *page;
+
+ xen_mc_batch();
+ for (i = 0; i < (1UL<<order); i++) {
+ if (!test_bit(i, limit_bitmap))
+ continue;
+
+ page = &pages[i];
+ mcs = __xen_mc_entry(0);
+#define DEBUG 1
+ if (in_frames) {
+#ifdef DEBUG
+ printk(KERN_INFO "%s:%d 0x%lx(pfn) 0x%lx (mfn) 0x%lx(vaddr)\n",
+ __func__, i, page_to_pfn(page),
+ pfn_to_mfn(page_to_pfn(page)), page_address(page)); #endif
+ in_frames[i] = pfn_to_mfn(page_to_pfn(page));
+ }
+ MULTI_update_va_mapping(mcs.mc, (unsigned long)page_address(page), VOID_PTE, 0);
+ set_phys_to_machine(page_to_pfn(page), INVALID_P2M_ENTRY);
+
+ if (out_frames)
+ out_frames[i] = page_to_pfn(page);
+ ++n;
+
+ }
+ xen_mc_issue(0);
+ return n;
+}

/*
* Update the pfn-to-mfn mappings for a virtual address range, either to @@ -2118,6 +2156,53 @@ static void xen_remap_exchanged_ptes(unsigned long vaddr, int order,

xen_mc_issue(0);
}
+static void xen_remap_exchanged_pages(struct page *pages, int order,
+ unsigned long *mfns,
+ unsigned long first_mfn, /* in_frame if we failed*/
+ void *limit_map)
+{
+ unsigned i, limit;
+ unsigned long mfn;
+ struct page *page;
+
+ xen_mc_batch();
+
+ limit = 1ULL << order;
+ for (i = 0; i < limit; i++) {
+ struct multicall_space mcs;
+ unsigned flags;
+
+ if (!test_bit(i, limit_map))
+ continue;
+
+ page = &pages[i];
+ mcs = __xen_mc_entry(0);
+ if (mfns)
+ mfn = mfns[i];
+ else
+ mfn = first_mfn + i;
+
+ if (i < (limit - 1))
+ flags = 0;
+ else {
+ if (order == 0)
+ flags = UVMF_INVLPG | UVMF_ALL;
+ else
+ flags = UVMF_TLB_FLUSH | UVMF_ALL;
+ }
+#ifdef DEBUG
+ printk(KERN_INFO "%s (%d) pfn:0x%lx, pfn: 0x%lx vaddr: 0x%lx\n",
+ __func__, i, page_to_pfn(page), mfn, page_address(page)); #endif
+ MULTI_update_va_mapping(mcs.mc, (unsigned long)page_address(page),
+ mfn_pte(mfn, PAGE_KERNEL), flags);
+
+ set_phys_to_machine(page_to_pfn(page), mfn);
+ }
+
+ xen_mc_issue(0);
+}
+

/*
* Perform the hypercall to exchange a region of our pfns to point to @@ -2136,7 +2221,9 @@ static int xen_exchange_memory(unsigned long extents_in, unsigned int order_in, {
long rc;
int success;
-
+#ifdef DEBUG
+ int i;
+#endif
struct xen_memory_exchange exchange = {
.in = {
.nr_extents = extents_in,
@@ -2157,7 +2244,11 @@ static int xen_exchange_memory(unsigned long extents_in, unsigned int order_in,

rc = HYPERVISOR_memory_op(XENMEM_exchange, &exchange);
success = (exchange.nr_exchanged == extents_in);
-
+#ifdef DEBUG
+ for (i = 0; i < exchange.nr_exchanged; i++) {
+ printk(KERN_INFO "%s 0x%lx (mfn) <-> 0x%lx (mfn)\n", __func__,pfns_in[i], mfns_out[i]);
+ }
+#endif
BUG_ON(!success && ((exchange.nr_exchanged != 0) || (rc == 0)));
BUG_ON(success && (rc != 0));

@@ -2231,8 +2322,8 @@ void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order)
xen_zap_pfn_range(vstart, order, NULL, out_frames);

/* 3. Do the exchange for non-contiguous MFNs. */
- success = xen_exchange_memory(1, order, &in_frame, 1UL << order,
- 0, out_frames, 0);
+ success = xen_exchange_memory(1, order, &in_frame,
+ 1UL << order, 0, out_frames, 0);

/* 4. Map new pages in place of old pages. */
if (success)
@@ -2244,6 +2335,94 @@ void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order) } EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);

+int xen_limit_pages_to_max_mfn(struct page *pages, unsigned int order,
+ unsigned int address_bits)
+{
+ unsigned long *in_frames = discontig_frames, *out_frames = limited_frames;
+ unsigned long flags;
+ struct page *page;
+ int success;
+ int i, n = 0;
+ unsigned long _limit_map;
+ unsigned long *limit_map;
+
+ if (xen_feature(XENFEAT_auto_translated_physmap))
+ return 0;
+
+ if (unlikely(order > MAX_CONTIG_ORDER))
+ return -ENOMEM;
+
+ if (BITS_PER_LONG >> order) {
+ limit_map = kzalloc(BITS_TO_LONGS(1U << order) *
+ sizeof(*limit_map), GFP_KERNEL);
+ if (unlikely(!limit_map))
+ return -ENOMEM;
+ } else
+ limit_map = &_limit_map;
+
+ /* 0. Construct our per page bitmap lookup. */
+
+ if (address_bits && (address_bits < PAGE_SHIFT))
+ return -EINVAL;
+
+ if (order)
+ bitmap_zero(limit_map, 1U << order);
+ else
+ __set_bit(0, limit_map);
+
+ /* 1. Clear the pages */
+ for (i = 0; i < (1ULL << order); i++) {
+ void *vaddr;
+ page = &pages[i];
+
+ vaddr = page_address(page);
+#ifdef DEBUG
+ printk(KERN_INFO "%s: page: %p vaddr: %p 0x%lx(mfn) 0x%lx(pfn)\n",
+__func__, page, vaddr, virt_to_mfn(vaddr), mfn_to_pfn(virt_to_mfn(vaddr))); #endif
+ if (address_bits) {
+ if (!(virt_to_mfn(vaddr) >> (address_bits - PAGE_SHIFT)))
+ continue;
+ __set_bit(i, limit_map);
+ }
+ if (!PageHighMem(page))
+ memset(vaddr, 0, PAGE_SIZE);
+ else {
+ memset(kmap(page), 0, PAGE_SIZE);
+ kunmap(page);
+ ++n;
+ }
+ }
+ /* Check to see if we actually have to do any work. */
+ if (bitmap_empty(limit_map, 1U << order)) {
+ if (limit_map != &_limit_map)
+ kfree(limit_map);
+ return 0;
+ }
+ if (n)
+ kmap_flush_unused();
+
+ spin_lock_irqsave(&xen_reservation_lock, flags);
+
+ /* 2. Zap current PTEs. */
+ n = xen_zap_page_range(pages, order, in_frames, NULL /*out_frames */,
+limit_map);
+
+ /* 3. Do the exchange for non-contiguous MFNs. */
+ success = xen_exchange_memory(n, 0 /* this is always called per page */, in_frames,
+ n, 0, out_frames, address_bits);
+
+ /* 4. Map new pages in place of old pages. */
+ if (success)
+ xen_remap_exchanged_pages(pages, order, out_frames, 0, limit_map);
+ else
+ xen_remap_exchanged_pages(pages, order, NULL, *in_frames, limit_map);
+
+ spin_unlock_irqrestore(&xen_reservation_lock, flags);
+ if (limit_map != &_limit_map)
+ kfree(limit_map);
+
+ return success ? 0 : -ENOMEM;
+}
+EXPORT_SYMBOL_GPL(xen_limit_pages_to_max_mfn);
#ifdef CONFIG_XEN_PVHVM
static void xen_hvm_exit_mmap(struct mm_struct *mm) { diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h index 6a198e4..2f8709f 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -29,4 +29,6 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
unsigned long mfn, int nr,
pgprot_t prot, unsigned domid);

+int xen_limit_pages_to_max_mfn(struct page *pages, unsigned int order,
+ unsigned int address_bits);
#endif /* INCLUDE_XEN_OPS_H */
diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 2aad499..194af07 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -31,6 +31,8 @@
#include <asm/tlbflush.h>
#include <asm/shmparam.h>

+#include <xen/xen.h>
+#include <xen/xen-ops.h>
/*** Page table manipulation functions ***/

static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end) @@ -1576,7 +1578,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
struct page **pages;
unsigned int nr_pages, array_size, i;
gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
-
+ gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
+ if (xen_pv_domain()) {
+ if (dma_mask == (__GFP_DMA | __GFP_DMA32))
+ gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);
+ }
nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
array_size = (nr_pages * sizeof(struct page *));

@@ -1612,6 +1618,16 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
goto fail;
}
area->pages[i] = page;
+ if (xen_pv_domain()) {
+ if (dma_mask) {
+ if (xen_limit_pages_to_max_mfn(page, 0, 32)) {
+ area->nr_pages = i + 1;
+ goto fail;
+ }
+ if (gfp_mask & __GFP_ZERO)
+ clear_highpage(page);
+ }
+ }
}

if (map_vm_area(area, prot, &pages))
--
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel

-----
E-Mail ist virenfrei.
Von AVG berprft - www.avg.de
Version: 2012.0.2180 / Virendatenbank: 2433/5067 - Ausgabedatum: 13.06.2012


_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel

-----
E-Mail ist virenfrei.
Von AVG berprft - www.avg.de
Version: 2012.0.2180 / Virendatenbank: 2433/5069 - Ausgabedatum: 14.06.2012


_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel

First page Previous page 1 2 3 Next page Last page  View All Xen devel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.