* [GIT PULL] (xen) stable/for-jens-3.10
@ 2013-04-19 14:44 Konrad Rzeszutek Wilk
[not found] ` <1094538380.20130424201637@eikelenboom.it>
0 siblings, 1 reply; 6+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-04-19 14:44 UTC (permalink / raw)
To: xen-devel, linux-kernel, axboe; +Cc: roger.pau
[-- Attachment #1: Type: text/plain, Size: 4682 bytes --]
Hey Jens,
Please in your spare time (if there is such a thing at a conference)
pull this branch:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.10
for your v3.10 branch. Sorry for being so late with this.
<blurb>
It has the 'feature-max-indirect-segments' implemented in both backend
and frontend. The current problem with the backend and frontend is that the
segment size is limited to 11 pages. It means we can at most squeeze in 44kB per
request. The ring can hold 32 (next power of two below 36) requests, meaning we
can do 1.4M of outstanding requests. Nowadays that is not enough.
The problem in the past was addressed in two ways - but neither one went upstream.
The first solution to this proposed by Justin from Spectralogic was to negotiate
the segment size. This means that the ‘struct blkif_sring_entry’ is now a variable size.
It can expand from 112 bytes (cover 11 pages of data - 44kB) to 1580 bytes
(256 pages of data - so 1MB). It is a simple extension by just making the array in the
request expand from 11 to a variable size negotiated. But it had limits: this extension
still limits the number of segments per request to 255 (as the total number must be
specified in the request, which only has an 8-bit field for that purpose).
The other solution (from Intel - Ronghui) was to create one extra ring that only has the
‘struct blkif_request_segment’ in them. The ‘struct blkif_request’ would be changed to have
an index in said ‘segment ring’. There is only one segment ring. This means that the size of
the initial ring is still the same. The requests would point to the segment and enumerate out
how many of the indexes it wants to use. The limit is of course the size of the segment.
If one assumes a one-page segment this means we can in one request cover ~4MB.
Those patches were posted as RFC and the author never followed up on the ideas on changing
it to be a bit more flexible.
There is yet another mechanism that could be employed (which these patches implement) - and it
borrows from VirtIO protocol. And that is the ‘indirect descriptors’. This very similar to
what Intel suggests, but with a twist. The twist is to negotiate how many of these
'segment' pages (aka indirect descriptor pages) we want to support (in reality we negotiate
how many entries in the segment we want to cover, and we module the number if it is
bigger than the segment size).
This means that with the existing 36 slots in the ring (single page) we can cover:
32 slots * each blkif_request_indirect covers: 512 * 4096 ~= 64M. Since we ample space
in the blkif_request_indirect to span more than one indirect page, that number (64M)
can be also multiplied by eight = 512MB.
Roger Pau Monne took the idea and implemented them in these patches. They work
great and the corner cases (migration between backends with and without this extension)
work nicely. The backend has a limit right now off how many indirect entries
it can handle: one indirect page, and at maximum 256 entries (out of 512 - so 50% of the page
is used). That comes out to 32 slots * 256 entries in a indirect page * 1 indirect page
per request * 4096 = 32MB.
This is a conservative number that can change in the future. Right now it strikes
a good balance between giving excellent performance, memory usage in the backend, and
balancing the needs of many guests.
In the patchset there is also the split of the blkback structure to be per-VBD.
This means that the spinlock contention we had with many guests trying to do I/O and
all the blkback threads hitting the same lock has been eliminated.
</blurb>
Anyhow, please pull and if possible include the nice overview I typed up in the
merge commit.
Documentation/ABI/stable/sysfs-bus-xen-backend | 18 +
drivers/block/xen-blkback/blkback.c | 843 ++++++++++++++++---------
drivers/block/xen-blkback/common.h | 145 ++++-
drivers/block/xen-blkback/xenbus.c | 38 ++
drivers/block/xen-blkfront.c | 490 +++++++++++---
include/xen/interface/io/blkif.h | 53 ++
6 files changed, 1188 insertions(+), 399 deletions(-)
Roger Pau Monne (7):
xen-blkback: print stats about persistent grants
xen-blkback: use balloon pages for all mappings
xen-blkback: implement LRU mechanism for persistent grants
xen-blkback: move pending handles list from blkbk to pending_req
xen-blkback: make the queue of free requests per backend
xen-blkback: expand map/unmap functions
xen-block: implement indirect descriptors
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.10 xenwatch: page allocation failure: order:7, mode:0x10c0d0
[not found] ` <1094538380.20130424201637@eikelenboom.it>
@ 2013-04-29 15:46 ` Konrad Rzeszutek Wilk
2013-04-29 16:05 ` Sander Eikelenboom
2013-04-29 19:14 ` Jens Axboe
0 siblings, 2 replies; 6+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-04-29 15:46 UTC (permalink / raw)
To: Sander Eikelenboom, axboe; +Cc: xen-devel, roger.pau, linux-kernel
On Wed, Apr 24, 2013 at 08:16:37PM +0200, Sander Eikelenboom wrote:
> Friday, April 19, 2013, 4:44:01 PM, you wrote:
>
> > Hey Jens,
>
> > Please in your spare time (if there is such a thing at a conference)
> > pull this branch:
>
> > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.10
>
.. snip..
> Hi Konrad / Roger,
>
> I tried this pull on top of latest Linus latest linux-3.9 tree, but although it seems to boot and work fine at first, i seem to get trouble after running for about a day.
> Without this pull it runs fine for several days.
.. snipp.
> [18496.013743] xenwatch: page allocation failure: order:7, mode:0x10c0d0
> [18496.031948] Pid: 54, comm: xenwatch Not tainted 3.9.0-rc8-20130424-jens+ #1
> [18496.049897] Call Trace:
> [18496.067674] [<ffffffff81100c51>] warn_alloc_failed+0xf1/0x140
> [18496.085453] [<ffffffff810b25ed>] ? trace_hardirqs_on+0xd/0x10
> [18496.102951] [<ffffffff810bdb24>] ? on_each_cpu_mask+0x94/0xd0
> [18496.120270] [<ffffffff811028af>] __alloc_pages_nodemask+0x69f/0x960
> [18496.137306] [<ffffffff8113a161>] alloc_pages_current+0xb1/0x160
> [18496.154051] [<ffffffff81100679>] __get_free_pages+0x9/0x40
> [18496.170579] [<ffffffff81142af4>] __kmalloc+0x134/0x160
> [18496.186921] [<ffffffff815832d0>] xen_blkbk_probe+0x170/0x2f0
> [18496.202963] [<ffffffff81474ce7>] xenbus_dev_probe+0x77/0x130
> [18496.218714] [<ffffffff8156a390>] ? __driver_attach+0xa0/0xa0
> [18496.234237] [<ffffffff8156a151>] driver_probe_device+0x81/0x220
> [18496.249605] [<ffffffff8198198c>] ? klist_next+0x8c/0x110
> [18496.264681] [<ffffffff8156a390>] ? __driver_attach+0xa0/0xa0
> [18496.279500] [<ffffffff8156a3db>] __device_attach+0x4b/0x50
> [18496.294138] [<ffffffff815684e8>] bus_for_each_drv+0x68/0x90
> [18496.308553] [<ffffffff8156a0c9>] device_attach+0x89/0x90
> [18496.322694] [<ffffffff81569258>] bus_probe_device+0xa8/0xd0
> [18496.336640] [<ffffffff81567c80>] device_add+0x650/0x720
.. snip..
Jens,
I don't know if you had pulled this git tree yet (I don't see it in
your for-3.10/* branches).
But if you have, Sander has found a bug (and Roger has a fix for it).
Whether you would like to wait until v3.11 to pull it (and me sending
the git pull around a month) is OK. Or pull it now and we will fix the
bugs in the -rc's as they creep up.
Thanks!
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.10 xenwatch: page allocation failure: order:7, mode:0x10c0d0
2013-04-29 15:46 ` [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.10 xenwatch: page allocation failure: order:7, mode:0x10c0d0 Konrad Rzeszutek Wilk
@ 2013-04-29 16:05 ` Sander Eikelenboom
2013-05-04 7:34 ` Sander Eikelenboom
2013-04-29 19:14 ` Jens Axboe
1 sibling, 1 reply; 6+ messages in thread
From: Sander Eikelenboom @ 2013-04-29 16:05 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: axboe, xen-devel, roger.pau, linux-kernel
Monday, April 29, 2013, 5:46:23 PM, you wrote:
> On Wed, Apr 24, 2013 at 08:16:37PM +0200, Sander Eikelenboom wrote:
>> Friday, April 19, 2013, 4:44:01 PM, you wrote:
>>
>> > Hey Jens,
>>
>> > Please in your spare time (if there is such a thing at a conference)
>> > pull this branch:
>>
>> > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.10
>>
> .. snip..
>> Hi Konrad / Roger,
>>
>> I tried this pull on top of latest Linus latest linux-3.9 tree, but although it seems to boot and work fine at first, i seem to get trouble after running for about a day.
>> Without this pull it runs fine for several days.
> .. snipp.
>> [18496.013743] xenwatch: page allocation failure: order:7, mode:0x10c0d0
>> [18496.031948] Pid: 54, comm: xenwatch Not tainted 3.9.0-rc8-20130424-jens+ #1
>> [18496.049897] Call Trace:
>> [18496.067674] [<ffffffff81100c51>] warn_alloc_failed+0xf1/0x140
>> [18496.085453] [<ffffffff810b25ed>] ? trace_hardirqs_on+0xd/0x10
>> [18496.102951] [<ffffffff810bdb24>] ? on_each_cpu_mask+0x94/0xd0
>> [18496.120270] [<ffffffff811028af>] __alloc_pages_nodemask+0x69f/0x960
>> [18496.137306] [<ffffffff8113a161>] alloc_pages_current+0xb1/0x160
>> [18496.154051] [<ffffffff81100679>] __get_free_pages+0x9/0x40
>> [18496.170579] [<ffffffff81142af4>] __kmalloc+0x134/0x160
>> [18496.186921] [<ffffffff815832d0>] xen_blkbk_probe+0x170/0x2f0
>> [18496.202963] [<ffffffff81474ce7>] xenbus_dev_probe+0x77/0x130
>> [18496.218714] [<ffffffff8156a390>] ? __driver_attach+0xa0/0xa0
>> [18496.234237] [<ffffffff8156a151>] driver_probe_device+0x81/0x220
>> [18496.249605] [<ffffffff8198198c>] ? klist_next+0x8c/0x110
>> [18496.264681] [<ffffffff8156a390>] ? __driver_attach+0xa0/0xa0
>> [18496.279500] [<ffffffff8156a3db>] __device_attach+0x4b/0x50
>> [18496.294138] [<ffffffff815684e8>] bus_for_each_drv+0x68/0x90
>> [18496.308553] [<ffffffff8156a0c9>] device_attach+0x89/0x90
>> [18496.322694] [<ffffffff81569258>] bus_probe_device+0xa8/0xd0
>> [18496.336640] [<ffffffff81567c80>] device_add+0x650/0x720
> .. snip..
> Jens,
> I don't know if you had pulled this git tree yet (I don't see it in
> your for-3.10/* branches).
> But if you have, Sander has found a bug (and Roger has a fix for it).
> Whether you would like to wait until v3.11 to pull it (and me sending
> the git pull around a month) is OK. Or pull it now and we will fix the
> bugs in the -rc's as they creep up.
Roger's fix seems to work for me ..
--
Sander
> Thanks!
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.10 xenwatch: page allocation failure: order:7, mode:0x10c0d0
2013-04-29 15:46 ` [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.10 xenwatch: page allocation failure: order:7, mode:0x10c0d0 Konrad Rzeszutek Wilk
2013-04-29 16:05 ` Sander Eikelenboom
@ 2013-04-29 19:14 ` Jens Axboe
1 sibling, 0 replies; 6+ messages in thread
From: Jens Axboe @ 2013-04-29 19:14 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Sander Eikelenboom, xen-devel, roger.pau, linux-kernel
On Mon, Apr 29 2013, Konrad Rzeszutek Wilk wrote:
> On Wed, Apr 24, 2013 at 08:16:37PM +0200, Sander Eikelenboom wrote:
> > Friday, April 19, 2013, 4:44:01 PM, you wrote:
> >
> > > Hey Jens,
> >
> > > Please in your spare time (if there is such a thing at a conference)
> > > pull this branch:
> >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.10
> >
>
> .. snip..
> > Hi Konrad / Roger,
> >
> > I tried this pull on top of latest Linus latest linux-3.9 tree, but although it seems to boot and work fine at first, i seem to get trouble after running for about a day.
> > Without this pull it runs fine for several days.
> .. snipp.
>
> > [18496.013743] xenwatch: page allocation failure: order:7, mode:0x10c0d0
> > [18496.031948] Pid: 54, comm: xenwatch Not tainted 3.9.0-rc8-20130424-jens+ #1
> > [18496.049897] Call Trace:
> > [18496.067674] [<ffffffff81100c51>] warn_alloc_failed+0xf1/0x140
> > [18496.085453] [<ffffffff810b25ed>] ? trace_hardirqs_on+0xd/0x10
> > [18496.102951] [<ffffffff810bdb24>] ? on_each_cpu_mask+0x94/0xd0
> > [18496.120270] [<ffffffff811028af>] __alloc_pages_nodemask+0x69f/0x960
> > [18496.137306] [<ffffffff8113a161>] alloc_pages_current+0xb1/0x160
> > [18496.154051] [<ffffffff81100679>] __get_free_pages+0x9/0x40
> > [18496.170579] [<ffffffff81142af4>] __kmalloc+0x134/0x160
> > [18496.186921] [<ffffffff815832d0>] xen_blkbk_probe+0x170/0x2f0
> > [18496.202963] [<ffffffff81474ce7>] xenbus_dev_probe+0x77/0x130
> > [18496.218714] [<ffffffff8156a390>] ? __driver_attach+0xa0/0xa0
> > [18496.234237] [<ffffffff8156a151>] driver_probe_device+0x81/0x220
> > [18496.249605] [<ffffffff8198198c>] ? klist_next+0x8c/0x110
> > [18496.264681] [<ffffffff8156a390>] ? __driver_attach+0xa0/0xa0
> > [18496.279500] [<ffffffff8156a3db>] __device_attach+0x4b/0x50
> > [18496.294138] [<ffffffff815684e8>] bus_for_each_drv+0x68/0x90
> > [18496.308553] [<ffffffff8156a0c9>] device_attach+0x89/0x90
> > [18496.322694] [<ffffffff81569258>] bus_probe_device+0xa8/0xd0
> > [18496.336640] [<ffffffff81567c80>] device_add+0x650/0x720
>
> .. snip..
>
> Jens,
> I don't know if you had pulled this git tree yet (I don't see it in
> your for-3.10/* branches).
>
> But if you have, Sander has found a bug (and Roger has a fix for it).
>
> Whether you would like to wait until v3.11 to pull it (and me sending
> the git pull around a month) is OK. Or pull it now and we will fix the
> bugs in the -rc's as they creep up.
Thanks for letting me know. Lets postpone it for 3.11. If you have more
critical bits in your current tree, you can send them in over this week.
--
Jens Axboe
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.10 xenwatch: page allocation failure: order:7, mode:0x10c0d0
2013-04-29 16:05 ` Sander Eikelenboom
@ 2013-05-04 7:34 ` Sander Eikelenboom
2013-05-06 9:00 ` Roger Pau Monné
0 siblings, 1 reply; 6+ messages in thread
From: Sander Eikelenboom @ 2013-05-04 7:34 UTC (permalink / raw)
To: roger.pau; +Cc: Konrad Rzeszutek Wilk, axboe, xen-devel, linux-kernel
Hello Sander,
Monday, April 29, 2013, 6:05:20 PM, you wrote:
> Monday, April 29, 2013, 5:46:23 PM, you wrote:
>> On Wed, Apr 24, 2013 at 08:16:37PM +0200, Sander Eikelenboom wrote:
>>> Friday, April 19, 2013, 4:44:01 PM, you wrote:
>>>
>>> > Hey Jens,
>>>
>>> > Please in your spare time (if there is such a thing at a conference)
>>> > pull this branch:
>>>
>>> > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.10
>>>
>> .. snip..
>>> Hi Konrad / Roger,
>>>
>>> I tried this pull on top of latest Linus latest linux-3.9 tree, but although it seems to boot and work fine at first, i seem to get trouble after running for about a day.
>>> Without this pull it runs fine for several days.
>> .. snipp.
>>> [18496.013743] xenwatch: page allocation failure: order:7, mode:0x10c0d0
>>> [18496.031948] Pid: 54, comm: xenwatch Not tainted 3.9.0-rc8-20130424-jens+ #1
>>> [18496.049897] Call Trace:
>>> [18496.067674] [<ffffffff81100c51>] warn_alloc_failed+0xf1/0x140
>>> [18496.085453] [<ffffffff810b25ed>] ? trace_hardirqs_on+0xd/0x10
>>> [18496.102951] [<ffffffff810bdb24>] ? on_each_cpu_mask+0x94/0xd0
>>> [18496.120270] [<ffffffff811028af>] __alloc_pages_nodemask+0x69f/0x960
>>> [18496.137306] [<ffffffff8113a161>] alloc_pages_current+0xb1/0x160
>>> [18496.154051] [<ffffffff81100679>] __get_free_pages+0x9/0x40
>>> [18496.170579] [<ffffffff81142af4>] __kmalloc+0x134/0x160
>>> [18496.186921] [<ffffffff815832d0>] xen_blkbk_probe+0x170/0x2f0
>>> [18496.202963] [<ffffffff81474ce7>] xenbus_dev_probe+0x77/0x130
>>> [18496.218714] [<ffffffff8156a390>] ? __driver_attach+0xa0/0xa0
>>> [18496.234237] [<ffffffff8156a151>] driver_probe_device+0x81/0x220
>>> [18496.249605] [<ffffffff8198198c>] ? klist_next+0x8c/0x110
>>> [18496.264681] [<ffffffff8156a390>] ? __driver_attach+0xa0/0xa0
>>> [18496.279500] [<ffffffff8156a3db>] __device_attach+0x4b/0x50
>>> [18496.294138] [<ffffffff815684e8>] bus_for_each_drv+0x68/0x90
>>> [18496.308553] [<ffffffff8156a0c9>] device_attach+0x89/0x90
>>> [18496.322694] [<ffffffff81569258>] bus_probe_device+0xa8/0xd0
>>> [18496.336640] [<ffffffff81567c80>] device_add+0x650/0x720
>> .. snip..
>> Jens,
>> I don't know if you had pulled this git tree yet (I don't see it in
>> your for-3.10/* branches).
>> But if you have, Sander has found a bug (and Roger has a fix for it).
>> Whether you would like to wait until v3.11 to pull it (and me sending
>> the git pull around a month) is OK. Or pull it now and we will fix the
>> bugs in the -rc's as they creep up.
> Roger's fix seems to work for me ..
Hmm although it takes longer, i still see my memory getting souped-up.
Will see what setting:
echo 384 > /sys/module/xen_blkback/parameters/max_persistent_grants
echo 256 >> /sys/module/xen_blkback/parameters/max_buffer_pages
will do this time around.
--
Sander
(XEN) [2013-05-03 23:00:21] grant_table.c:1250:d1 Expanding dom (1) grant table from (7) to (8) frames.
(XEN) [2013-05-03 23:00:41] grant_table.c:1250:d1 Expanding dom (1) grant table from (8) to (9) frames.
(XEN) [2013-05-03 23:01:01] grant_table.c:1250:d1 Expanding dom (1) grant table from (9) to (10) frames.
(XEN) [2013-05-03 23:01:01] grant_table.c:1250:d1 Expanding dom (1) grant table from (10) to (11) frames.
(XEN) [2013-05-04 03:15:32] grant_table.c:289:d0 Increased maptrack size to 10 frames
(XEN) [2013-05-04 03:15:34] grant_table.c:1250:d9 Expanding dom (9) grant table from (4) to (5) frames.
(XEN) [2013-05-04 03:15:34] grant_table.c:1250:d9 Expanding dom (9) grant table from (5) to (6) frames.
(XEN) [2013-05-04 03:15:34] grant_table.c:1250:d9 Expanding dom (9) grant table from (6) to (7) frames.
(XEN) [2013-05-04 03:15:34] grant_table.c:289:d0 Increased maptrack size to 11 frames
(XEN) [2013-05-04 03:15:36] grant_table.c:1250:d8 Expanding dom (8) grant table from (4) to (5) frames.
(XEN) [2013-05-04 03:15:36] grant_table.c:1250:d8 Expanding dom (8) grant table from (5) to (6) frames.
(XEN) [2013-05-04 03:15:36] grant_table.c:289:d0 Increased maptrack size to 12 frames
(XEN) [2013-05-04 03:15:36] grant_table.c:289:d0 Increased maptrack size to 13 frames
(XEN) [2013-05-04 03:15:37] grant_table.c:1250:d4 Expanding dom (4) grant table from (4) to (5) frames.
(XEN) [2013-05-04 03:15:37] grant_table.c:1250:d4 Expanding dom (4) grant table from (5) to (6) frames.
(XEN) [2013-05-04 03:15:37] grant_table.c:1250:d4 Expanding dom (4) grant table from (6) to (7) frames.
(XEN) [2013-05-04 03:15:37] grant_table.c:289:d0 Increased maptrack size to 14 frames
(XEN) [2013-05-04 03:15:37] grant_table.c:289:d0 Increased maptrack size to 15 frames
(XEN) [2013-05-04 03:15:39] grant_table.c:1250:d3 Expanding dom (3) grant table from (4) to (5) frames.
(XEN) [2013-05-04 03:15:39] grant_table.c:1250:d3 Expanding dom (3) grant table from (5) to (6) frames.
(XEN) [2013-05-04 03:15:39] grant_table.c:289:d0 Increased maptrack size to 16 frames
(XEN) [2013-05-04 03:15:39] grant_table.c:289:d0 Increased maptrack size to 17 frames
(XEN) [2013-05-04 03:15:39] grant_table.c:1250:d13 Expanding dom (13) grant table from (4) to (5) frames.
(XEN) [2013-05-04 03:15:39] grant_table.c:1250:d13 Expanding dom (13) grant table from (5) to (6) frames.
(XEN) [2013-05-04 03:15:39] grant_table.c:1250:d13 Expanding dom (13) grant table from (6) to (7) frames.
(XEN) [2013-05-04 03:15:39] grant_table.c:289:d0 Increased maptrack size to 18 frames
(XEN) [2013-05-04 03:15:39] grant_table.c:1250:d3 Expanding dom (3) grant table from (6) to (7) frames.
(XEN) [2013-05-04 03:15:39] grant_table.c:289:d0 Increased maptrack size to 19 frames
(XEN) [2013-05-04 03:15:40] grant_table.c:1250:d8 Expanding dom (8) grant table from (6) to (7) frames.
(XEN) [2013-05-04 03:15:42] grant_table.c:1250:d2 Expanding dom (2) grant table from (4) to (5) frames.
(XEN) [2013-05-04 03:15:42] grant_table.c:1250:d2 Expanding dom (2) grant table from (5) to (6) frames.
(XEN) [2013-05-04 03:15:42] grant_table.c:289:d0 Increased maptrack size to 20 frames
(XEN) [2013-05-04 03:15:42] grant_table.c:289:d0 Increased maptrack size to 21 frames
(XEN) [2013-05-04 03:15:42] grant_table.c:1250:d2 Expanding dom (2) grant table from (6) to (7) frames.
(XEN) [2013-05-04 03:15:43] grant_table.c:1250:d10 Expanding dom (10) grant table from (4) to (5) frames.
(XEN) [2013-05-04 03:15:44] grant_table.c:1250:d10 Expanding dom (10) grant table from (5) to (6) frames.
(XEN) [2013-05-04 03:15:44] grant_table.c:289:d0 Increased maptrack size to 22 frames
(XEN) [2013-05-04 03:15:44] grant_table.c:1250:d10 Expanding dom (10) grant table from (6) to (7) frames.
(XEN) [2013-05-04 03:15:45] grant_table.c:1250:d5 Expanding dom (5) grant table from (4) to (5) frames.
(XEN) [2013-05-04 03:15:45] grant_table.c:1250:d5 Expanding dom (5) grant table from (5) to (6) frames.
(XEN) [2013-05-04 03:15:45] grant_table.c:1250:d5 Expanding dom (5) grant table from (6) to (7) frames.
(XEN) [2013-05-04 03:15:45] grant_table.c:289:d0 Increased maptrack size to 23 frames
(XEN) [2013-05-04 03:15:45] grant_table.c:289:d0 Increased maptrack size to 24 frames
(XEN) [2013-05-04 03:15:50] grant_table.c:1250:d7 Expanding dom (7) grant table from (4) to (5) frames.
(XEN) [2013-05-04 03:15:50] grant_table.c:1250:d7 Expanding dom (7) grant table from (5) to (6) frames.
(XEN) [2013-05-04 03:15:50] grant_table.c:1250:d7 Expanding dom (7) grant table from (6) to (7) frames.
(XEN) [2013-05-04 03:15:50] grant_table.c:289:d0 Increased maptrack size to 25 frames
(XEN) [2013-05-04 03:15:52] grant_table.c:289:d0 Increased maptrack size to 26 frames
(XEN) [2013-05-04 03:16:04] grant_table.c:1250:d12 Expanding dom (12) grant table from (4) to (5) frames.
(XEN) [2013-05-04 03:16:05] grant_table.c:1250:d12 Expanding dom (12) grant table from (5) to (6) frames.
(XEN) [2013-05-04 03:16:05] grant_table.c:289:d0 Increased maptrack size to 27 frames
(XEN) [2013-05-04 03:16:05] grant_table.c:1250:d12 Expanding dom (12) grant table from (6) to (7) frames.
(XEN) [2013-05-04 05:15:05] grant_table.c:289:d0 Increased maptrack size to 28 frames
(XEN) [2013-05-04 05:15:09] grant_table.c:1250:d6 Expanding dom (6) grant table from (4) to (5) frames.
(XEN) [2013-05-04 05:15:09] grant_table.c:1250:d6 Expanding dom (6) grant table from (5) to (6) frames.
(XEN) [2013-05-04 05:15:09] grant_table.c:1250:d6 Expanding dom (6) grant table from (6) to (7) frames.
(XEN) [2013-05-04 05:15:09] grant_table.c:289:d0 Increased maptrack size to 29 frames
> --
> Sander
>> Thanks!
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.10 xenwatch: page allocation failure: order:7, mode:0x10c0d0
2013-05-04 7:34 ` Sander Eikelenboom
@ 2013-05-06 9:00 ` Roger Pau Monné
0 siblings, 0 replies; 6+ messages in thread
From: Roger Pau Monné @ 2013-05-06 9:00 UTC (permalink / raw)
To: Sander Eikelenboom
Cc: Konrad Rzeszutek Wilk, axboe@kernel.dk,
xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
On 04/05/13 09:34, Sander Eikelenboom wrote:
> Hello Sander,
>
> Monday, April 29, 2013, 6:05:20 PM, you wrote:
>
>
>> Monday, April 29, 2013, 5:46:23 PM, you wrote:
>
>>> On Wed, Apr 24, 2013 at 08:16:37PM +0200, Sander Eikelenboom wrote:
>>>> Friday, April 19, 2013, 4:44:01 PM, you wrote:
>>>>
>>>>> Hey Jens,
>>>>
>>>>> Please in your spare time (if there is such a thing at a conference)
>>>>> pull this branch:
>>>>
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.10
>>>>
>
>>> .. snip..
>>>> Hi Konrad / Roger,
>>>>
>>>> I tried this pull on top of latest Linus latest linux-3.9 tree, but although it seems to boot and work fine at first, i seem to get trouble after running for about a day.
>>>> Without this pull it runs fine for several days.
>>> .. snipp.
>
>>>> [18496.013743] xenwatch: page allocation failure: order:7, mode:0x10c0d0
>>>> [18496.031948] Pid: 54, comm: xenwatch Not tainted 3.9.0-rc8-20130424-jens+ #1
>>>> [18496.049897] Call Trace:
>>>> [18496.067674] [<ffffffff81100c51>] warn_alloc_failed+0xf1/0x140
>>>> [18496.085453] [<ffffffff810b25ed>] ? trace_hardirqs_on+0xd/0x10
>>>> [18496.102951] [<ffffffff810bdb24>] ? on_each_cpu_mask+0x94/0xd0
>>>> [18496.120270] [<ffffffff811028af>] __alloc_pages_nodemask+0x69f/0x960
>>>> [18496.137306] [<ffffffff8113a161>] alloc_pages_current+0xb1/0x160
>>>> [18496.154051] [<ffffffff81100679>] __get_free_pages+0x9/0x40
>>>> [18496.170579] [<ffffffff81142af4>] __kmalloc+0x134/0x160
>>>> [18496.186921] [<ffffffff815832d0>] xen_blkbk_probe+0x170/0x2f0
>>>> [18496.202963] [<ffffffff81474ce7>] xenbus_dev_probe+0x77/0x130
>>>> [18496.218714] [<ffffffff8156a390>] ? __driver_attach+0xa0/0xa0
>>>> [18496.234237] [<ffffffff8156a151>] driver_probe_device+0x81/0x220
>>>> [18496.249605] [<ffffffff8198198c>] ? klist_next+0x8c/0x110
>>>> [18496.264681] [<ffffffff8156a390>] ? __driver_attach+0xa0/0xa0
>>>> [18496.279500] [<ffffffff8156a3db>] __device_attach+0x4b/0x50
>>>> [18496.294138] [<ffffffff815684e8>] bus_for_each_drv+0x68/0x90
>>>> [18496.308553] [<ffffffff8156a0c9>] device_attach+0x89/0x90
>>>> [18496.322694] [<ffffffff81569258>] bus_probe_device+0xa8/0xd0
>>>> [18496.336640] [<ffffffff81567c80>] device_add+0x650/0x720
>
>>> .. snip..
>
>>> Jens,
>>> I don't know if you had pulled this git tree yet (I don't see it in
>>> your for-3.10/* branches).
>
>>> But if you have, Sander has found a bug (and Roger has a fix for it).
>
>>> Whether you would like to wait until v3.11 to pull it (and me sending
>>> the git pull around a month) is OK. Or pull it now and we will fix the
>>> bugs in the -rc's as they creep up.
>
>> Roger's fix seems to work for me ..
>
> Hmm although it takes longer, i still see my memory getting souped-up.
> Will see what setting:
>
> echo 384 > /sys/module/xen_blkback/parameters/max_persistent_grants
> echo 256 >> /sys/module/xen_blkback/parameters/max_buffer_pages
>
> will do this time around.
The error message is the same?
>
> --
> Sander
>
>
> (XEN) [2013-05-03 23:00:21] grant_table.c:1250:d1 Expanding dom (1) grant table from (7) to (8) frames.
> (XEN) [2013-05-03 23:00:41] grant_table.c:1250:d1 Expanding dom (1) grant table from (8) to (9) frames.
> (XEN) [2013-05-03 23:01:01] grant_table.c:1250:d1 Expanding dom (1) grant table from (9) to (10) frames.
> (XEN) [2013-05-03 23:01:01] grant_table.c:1250:d1 Expanding dom (1) grant table from (10) to (11) frames.
> (XEN) [2013-05-04 03:15:32] grant_table.c:289:d0 Increased maptrack size to 10 frames
> (XEN) [2013-05-04 03:15:34] grant_table.c:1250:d9 Expanding dom (9) grant table from (4) to (5) frames.
> (XEN) [2013-05-04 03:15:34] grant_table.c:1250:d9 Expanding dom (9) grant table from (5) to (6) frames.
> (XEN) [2013-05-04 03:15:34] grant_table.c:1250:d9 Expanding dom (9) grant table from (6) to (7) frames.
> (XEN) [2013-05-04 03:15:34] grant_table.c:289:d0 Increased maptrack size to 11 frames
> (XEN) [2013-05-04 03:15:36] grant_table.c:1250:d8 Expanding dom (8) grant table from (4) to (5) frames.
> (XEN) [2013-05-04 03:15:36] grant_table.c:1250:d8 Expanding dom (8) grant table from (5) to (6) frames.
> (XEN) [2013-05-04 03:15:36] grant_table.c:289:d0 Increased maptrack size to 12 frames
> (XEN) [2013-05-04 03:15:36] grant_table.c:289:d0 Increased maptrack size to 13 frames
> (XEN) [2013-05-04 03:15:37] grant_table.c:1250:d4 Expanding dom (4) grant table from (4) to (5) frames.
> (XEN) [2013-05-04 03:15:37] grant_table.c:1250:d4 Expanding dom (4) grant table from (5) to (6) frames.
> (XEN) [2013-05-04 03:15:37] grant_table.c:1250:d4 Expanding dom (4) grant table from (6) to (7) frames.
> (XEN) [2013-05-04 03:15:37] grant_table.c:289:d0 Increased maptrack size to 14 frames
> (XEN) [2013-05-04 03:15:37] grant_table.c:289:d0 Increased maptrack size to 15 frames
> (XEN) [2013-05-04 03:15:39] grant_table.c:1250:d3 Expanding dom (3) grant table from (4) to (5) frames.
> (XEN) [2013-05-04 03:15:39] grant_table.c:1250:d3 Expanding dom (3) grant table from (5) to (6) frames.
> (XEN) [2013-05-04 03:15:39] grant_table.c:289:d0 Increased maptrack size to 16 frames
> (XEN) [2013-05-04 03:15:39] grant_table.c:289:d0 Increased maptrack size to 17 frames
> (XEN) [2013-05-04 03:15:39] grant_table.c:1250:d13 Expanding dom (13) grant table from (4) to (5) frames.
> (XEN) [2013-05-04 03:15:39] grant_table.c:1250:d13 Expanding dom (13) grant table from (5) to (6) frames.
> (XEN) [2013-05-04 03:15:39] grant_table.c:1250:d13 Expanding dom (13) grant table from (6) to (7) frames.
> (XEN) [2013-05-04 03:15:39] grant_table.c:289:d0 Increased maptrack size to 18 frames
> (XEN) [2013-05-04 03:15:39] grant_table.c:1250:d3 Expanding dom (3) grant table from (6) to (7) frames.
> (XEN) [2013-05-04 03:15:39] grant_table.c:289:d0 Increased maptrack size to 19 frames
> (XEN) [2013-05-04 03:15:40] grant_table.c:1250:d8 Expanding dom (8) grant table from (6) to (7) frames.
> (XEN) [2013-05-04 03:15:42] grant_table.c:1250:d2 Expanding dom (2) grant table from (4) to (5) frames.
> (XEN) [2013-05-04 03:15:42] grant_table.c:1250:d2 Expanding dom (2) grant table from (5) to (6) frames.
> (XEN) [2013-05-04 03:15:42] grant_table.c:289:d0 Increased maptrack size to 20 frames
> (XEN) [2013-05-04 03:15:42] grant_table.c:289:d0 Increased maptrack size to 21 frames
> (XEN) [2013-05-04 03:15:42] grant_table.c:1250:d2 Expanding dom (2) grant table from (6) to (7) frames.
> (XEN) [2013-05-04 03:15:43] grant_table.c:1250:d10 Expanding dom (10) grant table from (4) to (5) frames.
> (XEN) [2013-05-04 03:15:44] grant_table.c:1250:d10 Expanding dom (10) grant table from (5) to (6) frames.
> (XEN) [2013-05-04 03:15:44] grant_table.c:289:d0 Increased maptrack size to 22 frames
> (XEN) [2013-05-04 03:15:44] grant_table.c:1250:d10 Expanding dom (10) grant table from (6) to (7) frames.
> (XEN) [2013-05-04 03:15:45] grant_table.c:1250:d5 Expanding dom (5) grant table from (4) to (5) frames.
> (XEN) [2013-05-04 03:15:45] grant_table.c:1250:d5 Expanding dom (5) grant table from (5) to (6) frames.
> (XEN) [2013-05-04 03:15:45] grant_table.c:1250:d5 Expanding dom (5) grant table from (6) to (7) frames.
> (XEN) [2013-05-04 03:15:45] grant_table.c:289:d0 Increased maptrack size to 23 frames
> (XEN) [2013-05-04 03:15:45] grant_table.c:289:d0 Increased maptrack size to 24 frames
> (XEN) [2013-05-04 03:15:50] grant_table.c:1250:d7 Expanding dom (7) grant table from (4) to (5) frames.
> (XEN) [2013-05-04 03:15:50] grant_table.c:1250:d7 Expanding dom (7) grant table from (5) to (6) frames.
> (XEN) [2013-05-04 03:15:50] grant_table.c:1250:d7 Expanding dom (7) grant table from (6) to (7) frames.
> (XEN) [2013-05-04 03:15:50] grant_table.c:289:d0 Increased maptrack size to 25 frames
> (XEN) [2013-05-04 03:15:52] grant_table.c:289:d0 Increased maptrack size to 26 frames
> (XEN) [2013-05-04 03:16:04] grant_table.c:1250:d12 Expanding dom (12) grant table from (4) to (5) frames.
> (XEN) [2013-05-04 03:16:05] grant_table.c:1250:d12 Expanding dom (12) grant table from (5) to (6) frames.
> (XEN) [2013-05-04 03:16:05] grant_table.c:289:d0 Increased maptrack size to 27 frames
> (XEN) [2013-05-04 03:16:05] grant_table.c:1250:d12 Expanding dom (12) grant table from (6) to (7) frames.
> (XEN) [2013-05-04 05:15:05] grant_table.c:289:d0 Increased maptrack size to 28 frames
> (XEN) [2013-05-04 05:15:09] grant_table.c:1250:d6 Expanding dom (6) grant table from (4) to (5) frames.
> (XEN) [2013-05-04 05:15:09] grant_table.c:1250:d6 Expanding dom (6) grant table from (5) to (6) frames.
> (XEN) [2013-05-04 05:15:09] grant_table.c:1250:d6 Expanding dom (6) grant table from (6) to (7) frames.
> (XEN) [2013-05-04 05:15:09] grant_table.c:289:d0 Increased maptrack size to 29 frames
All this messages are expected.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-05-06 9:00 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-04-19 14:44 [GIT PULL] (xen) stable/for-jens-3.10 Konrad Rzeszutek Wilk
[not found] ` <1094538380.20130424201637@eikelenboom.it>
2013-04-29 15:46 ` [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.10 xenwatch: page allocation failure: order:7, mode:0x10c0d0 Konrad Rzeszutek Wilk
2013-04-29 16:05 ` Sander Eikelenboom
2013-05-04 7:34 ` Sander Eikelenboom
2013-05-06 9:00 ` Roger Pau Monné
2013-04-29 19:14 ` Jens Axboe
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox