segments that have not been set.
Signed-off-by: Roger Pau Monne roger@citrix.com
Cc: konrad.w...@oracle.com
Cc: linux-kernel@vger.kernel.org
---
drivers/block/xen-blkback/blkback.c | 15 +--
drivers/block/xen-blkback/xenbus.c |2 +-
drivers/block/xen-blkfront.c|3
of using persistent grants. There is
perhaps a small saving, from the reduced number of hypercalls
performed in granting, and ending foreign access.
Signed-off-by: Oliver Chick oliver.ch...@citrix.com
Signed-off-by: Roger Pau Monne roger@citrix.com
Cc: konrad.w...@oracle.com
Cc: linux-kernel
saving, from the reduced number of hypercalls
performed in granting, and ending foreign access.
Signed-off-by: Oliver Chick oliver.ch...@citrix.com
Signed-off-by: Roger Pau Monne roger@citrix.com
Cc: konrad.w...@oracle.com
Cc: linux-kernel@vger.kernel.org
---
Benchmarks showing the impact
Moving grant ref handles from blkbk to pending_req will allow us to
get rid of the shared blkbk structure.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: xen-de...@lists.xen.org
---
drivers/block/xen-blkback/blkback.c | 16
Implementation of indirect descriptors v2, addressing Konrad's
comments. A graph on performance can be found at:
http://xenbits.xen.org/people/royger/plot_indirect_read4k.png
Thanks for the review, Roger.
Roger Pau Monne (7):
xen-blkback: print stats about persistent grants
xen
Using balloon pages for all granted pages allows us to simplify the
logic in blkback, especially in the xen_blkbk_map function, since now
we can decide if we want to map a grant persistently or not after we
have actually mapped it. This could not be done before because
persistent grants used
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: xen-de...@lists.xen.org
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
drivers/block/xen-blkback/blkback.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c
Indirect descriptors introduce a new block operation
(BLKIF_OP_INDIRECT) that passes grant references instead of segments
in the request. This grant references are filled with arrays of
blkif_request_segment_aligned, this way we can send more segments in a
request.
The proposed implementation
Preparatory change for implementing indirect descriptors. Change
xen_blkbk_{map/unmap} in order to be able to map/unmap a random amount
of grants (previously it was limited to
BLKIF_MAX_SEGMENTS_PER_REQUEST). Also, remove the usage of pending_req
in the map/unmap functions, so we can map/unmap
This mechanism allows blkback to change the number of grants
persistently mapped at run time.
The algorithm uses a simple LRU mechanism that removes (if needed) the
persistent grants that have not been used since the last LRU run, or
if all grants have been used it removes the first grants in the
Remove the last dependency from blkbk by moving the list of free
requests to blkif. This change reduces the contention on the list of
available requests.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: xen-de...@lists.xen.org
---
Changes
Indirect descriptors introduce a new block operation
(BLKIF_OP_INDIRECT) that passes grant references instead of segments
in the request. This grant references are filled with arrays of
blkif_request_segment_aligned, this way we can send more segments in a
request.
The proposed implementation
This series contains the cleanups and fixes found in my previous
indirect descriptors series, that are aimed for linux 3.9.
Available in the git repository at:
git://xenbits.xen.org/people/royger/linux.git blk-for-3.9
Roger Pau Monne (5):
xen-blkback: don't store dev_bus_addr
xen
dev_bus_addr returned in the grant ref map operation is the mfn of the
passed page, there's no need to store it in the persistent grant
entry, since we can always get it provided that we have the page.
This reduces the memory overhead of persistent grants in blkback.
Signed-off-by: Roger Pau
We may use foreach_grant_safe in the future with empty lists, so make
sure we can handle them.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: xen-de...@lists.xen.org
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
drivers/block/xen-blkback/blkback.c |2 +-
1 files changed, 1
We already have the frame (pfn of the grant page) stored inside struct
grant, so there's no need to keep an aditional list of mapped frames
for a specific request. This reduces memory usage in blkfront.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Konrad Rzeszutek Wilk
This prevents us from having to call alloc_page while we are preparing
the request. Since blkfront was calling alloc_page with a spinlock
held we used GFP_ATOMIC, which can fail if we are requesting a lot of
pages since it is using the emergency memory pools.
Allocating all the pages at init
Replace the use of llist with list.
llist_for_each_entry_safe can trigger a bug in GCC 4.1, so it's best
to remove it and use a doubly linked list, which is used extensively
in the kernel already.
Specifically this bug can be triggered by hot-unplugging a disk,
either by doing xm block-detach or
accurate comparison:
http://xenbits.xen.org/people/royger/plot_indirect_read4k.png
Also, the default number of segments per indirect request has been set
to 32 in order to map them all persistently, but this can be changed
at runtime by the user.
Roger Pau Monne (7):
xen-blkback: print
This mechanism allows blkback to change the number of grants
persistently mapped at run time.
The algorithm uses a simple LRU mechanism that removes (if needed) the
persistent grants that have not been used since the last LRU run, or
if all grants have been used it removes the first grants in the
Using balloon pages for all granted pages allows us to simplify the
logic in blkback, especially in the xen_blkbk_map function, since now
we can decide if we want to map a grant persistently or not after we
have actually mapped it. This could not be done before because
persistent grants used
Moving grant ref handles from blkbk to pending_req will allow us to
get rid of the shared blkbk structure.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: xen-de...@lists.xen.org
---
drivers/block/xen-blkback/blkback.c | 16
Indirect descriptors introduce a new block operation
(BLKIF_OP_INDIRECT) that passes grant references instead of segments
in the request. This grant references are filled with arrays of
blkif_request_segment_aligned, this way we can send more segments in a
request.
The proposed implementation
Preparatory change for implementing indirect descriptors. Change
xen_blkbk_{map/unmap} in order to be able to map/unmap a random amount
of grants (previously it was limited to
BLKIF_MAX_SEGMENTS_PER_REQUEST). Also, remove the usage of pending_req
in the map/unmap functions, so we can map/unmap
Remove the last dependency from blkbk by moving the list of free
requests to blkif. This change reduces the contention on the list of
available requests.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: xen-de...@lists.xen.org
---
Changes
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: xen-de...@lists.xen.org
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
drivers/block/xen-blkback/blkback.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c
Change foreach_grant iterator to a safe version, that allows freeing
the element while iterating. Also move the free code in
free_persistent_gnts to prevent freeing the element before the rb_next
call.
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Roger Pau Monné
Implement a safe version of llist_for_each_entry, and use it in
blkif_free. Previously grants where freed while iterating the list,
which lead to dereferences when trying to fetch the next item.
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Roger Pau Monné
Replace llist_for_each_entry_safe with a while loop and
llist_del_first.
llist_for_each_entry_safe can trigger a bug in GCC 4.1, so it's best
to remove it and use a while loop and llist_del_first (which is
already in llist.h).
Since xen-blkfront is the only user of the llist_for_each_entry_safe
dev_bus_addr returned in the grant ref map operation is the mfn of the
passed page, there's no need to store it in the persistent grant
entry, since we can always get it provided that we have the page.
This reduces the memory overhead of persistent grants in blkback.
Signed-off-by: Roger Pau
Moving grant ref handles from blkbk to pending_req will allow us to
get rid of the shared blkbk structure.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: xen-de...@lists.xen.org
---
drivers/block/xen-blkback/blkback.c | 16
Indirect descriptors introduce a new block operation
(BLKIF_OP_INDIRECT) that passes grant references instead of segments
in the request. This grant references are filled with arrays of
blkif_request_segment_aligned, this way we can send more segments in a
request.
The proposed implementation
Preparatory change for implementing indirect descriptors. Change
xen_blkbk_{map/unmap} in order to be able to map/unmap a random amount
of grants (previously it was limited to
BLKIF_MAX_SEGMENTS_PER_REQUEST). Also, remove the usage of pending_req
in the map/unmap functions, so we can map/unmap
Remove the last dependency from blkbk by moving the list of free
requests to blkif. This change reduces the contention on the list of
available requests.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: xen-de...@lists.xen.org
---
Using balloon pages for all granted pages allows us to simplify the
logic in blkback, specially in the xen_blkbk_map function, since now
we can decide if we want to map a grant persistently or not after we
have actually mapped it. This could not be done before because
persistent grants used
This mechanism allows blkback to change the number of grants
persistently mapped at run time.
The algorithm uses a simple LRU mechanism that removes (if needed) the
persistent grants that have not been used since the last LRU run, or
if all grants have been used it removes the first grants in the
This series contains the initial implementation of indirect
descriptors for Linux blkback/blkfront.
Patches 1, 2, 3, 4 and 5 are bug fixes and minor optimizations.
Patch 6 contains a LRU implementation for blkback that will be needed
when using indirect descriptors (since we are no longer able
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: xen-de...@lists.xen.org
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
drivers/block/xen-blkback/blkback.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c
This prevents us from having to call alloc_page while we are preparing
the request. Since blkfront was calling alloc_page with a spinlock
held we used GFP_ATOMIC, which can fail if we are requesting a lot of
pages since it is using the emergency memory pools.
Allocating all the pages at init
We already have the frame (pfn of the grant page) stored inside struct
grant, so there's no need to keep an aditional list of mapped frames
for a specific request. This reduces memory usage in blkfront.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Konrad Rzeszutek Wilk
Replace the use of llist with list.
llist_for_each_entry_safe can trigger a bug in GCC 4.1, so it's best
to remove it and use a doubly linked list, which is used extensively
in the kernel already.
Specifically this bug can be triggered by hot-unplugging a disk,
either by doing xm block-detach or
We may use foreach_grant_safe in the future with empty lists, so make
sure we can handle them.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: xen-de...@lists.xen.org
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
drivers/block/xen-blkback/blkback.c |2 +-
1 files changed, 1
With current persistent grants implementation we are not freeing the
persistent grants after we disconnect the device. Since grant map
operations change the mfn of the allocated page, and we can no longer
pass it to __free_page without setting the mfn to a sane value, use
balloon grant pages
Replace the use of llist with list.
llist_for_each_entry_safe can trigger a bug in GCC 4.1, so it's best
to remove it and use a doubly linked list, which is used extensively
in the kernel already.
Specifically this bug can be triggered by hot-unplugging a disk,
either by doing xm block-detach or
David Vrabel wrote:
On 09/07/12 15:45, Konrad Rzeszutek Wilk wrote:
On Fri, Jun 22, 2012 at 05:14:41PM +0100, Stefano Stabellini wrote:
We used to rely on a core_initcall to initialize Xen on ARM, however
core_initcalls are actually called after early consoles are initialized.
That means that
Currently blkfront fails to handle cases in blkif_completion like the
following:
1st loop in rq_for_each_segment
* bv_offset: 3584
* bv_len: 512
* offset += bv_len
* i: 0
2nd loop:
* bv_offset: 0
* bv_len: 512
* i: 0
In the second loop i should be 1, since we assume we only wanted to
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Huang Ying ying.hu...@intel.com
Cc: Konrad Rzeszutek Wilk kon...@kernel.org
---
include/linux/llist.h | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/include/linux/llist.h
Change foreach_grant iterator to a safe version, that allows freeing
the element while iterating. Also move the free code in
free_persistent_gnts to prevent freeing the element before the rb_next
call.
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Roger Pau Monné
Use llist_for_each_entry_safe in blkif_free. Previously grants where
freed while iterating the list, which lead to dereferences when trying
to fetch the next item.
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Konrad Rzeszutek Wilk
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Huang Ying ying.hu...@intel.com
Cc: Konrad Rzeszutek Wilk kon...@kernel.org
---
Changes since v2:
* Allow to pass a NULL node as the first entry of deleted list
entries.
---
include/linux/llist.h | 27 +++
1
Use llist_for_each_entry_safe in blkif_free. Previously grants where
freed while iterating the list, which lead to dereferences when trying
to fetch the next item.
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Konrad Rzeszutek Wilk
Change foreach_grant iterator to a safe version, that allows freeing
the element while iterating. Also move the free code in
free_persistent_gnts to prevent freeing the element before the rb_next
call.
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Roger Pau Monné
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Huang Ying ying.hu...@intel.com
Cc: Konrad Rzeszutek Wilk kon...@kernel.org
---
Changes since v3:
* Change n to use type *, to keep the same semantics as
list_for_each_entry_safe.
Changes since v2:
* Allow to pass a NULL node as the
Free the page allocated for the persistent grant.
Signed-off-by: Roger Pau Monné roger@citrix.com
---
drivers/block/xen-blkfront.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index f1de806..96e9b00
Move the code that frees persistent grants from the red-black tree
to a function. This will make it easier for other consumers to move
this to a common place.
Signed-off-by: Roger Pau Monné roger@citrix.com
---
drivers/block/xen-blkback/blkback.c | 68 +++
1
The new GNTTABOP_unmap_and_duplicate operation doesn't zero the
mapping passed in new_addr, allowing us to perform batch unmaps in p2m
code without requiring the use of a multicall.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc:
The code generat with gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-54)
creates an unbound loop for the second foreach_grant_safe loop in
purge_persistent_gnt.
The workaround is to avoid having this second loop and instead
perform all the work inside the first loop by adding a new variable,
clean_used,
Now that indirect segments are enabled blk_queue_max_hw_sectors must
be set to match the maximum number of sectors we can handle in a
request.
Signed-off-by: Roger Pau Monné roger@citrix.com
Reported-by: Felipe Franciosi felipe.franci...@citrix.com
Cc: Konrad Rzeszutek Wilk
When using certain storage devices (like RAID) having a bigger number
of segments per request provides better performance.
Signed-off-by: Roger Pau Monné roger@citrix.com
Reported-by: Steven Haigh net...@crc.id.au
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
This series contains a small number of bug fixes and improvements for
xen-block indirect descriptors.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
With the introduction of indirect segments we can receive requests
with a number of segments bigger than the maximum number of allowed
iovecs in a bios, so make sure that blkback doesn't try to allocate a
bios with more iovecs than BIO_MAX_PAGES
Signed-off-by: Roger Pau Monné roger@citrix.com
This series contain a small bugfix for the grant table code (patch 1)
and a couple of improvements to blkfront (patches 2 and 3) to make it
work better if there's a shortage on available free grants.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
There's no need to keep the foreign access in a grant if it is not
persistently mapped by the backend. This allows us to free grants that
are not mapped by the backend, thus preventing blkfront from hoarding
all grants.
The main effect of this is that blkfront will only persistently map
the same
Improve the calculation of required grants to process a request by
using nr_phys_segments instead of always assuming a request is going
to use all posible segments.
nr_phys_segments contains the number of scatter-gather DMA addr+len
pairs, which is basically what we put at every granted page.
With the current implementation, the callback in the tail of the list
can be added twice, because the check done in
gnttab_request_free_callback is bogus, callback-next can be NULL if
it is the last callback in the list. If we add the same callback twice
we end up with an infinite loop, were
The new GNTTABOP_unmap_and_duplicate operation doesn't zero the
mapping passed in new_addr, allowing us to perform batch unmaps in p2m
code without requiring the use of a multicall.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc:
The new GNTTABOP_unmap_and_duplicate operation doesn't zero the
mapping passed in new_addr, allowing us to perform batch unmaps in p2m
code without requiring the use of a multicall.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc:
Right now the maximum number of grant operations that can be batched
in a single request is BLKIF_MAX_SEGMENTS_PER_REQUEST (11). This was
OK before indirect descriptors because the maximum number of segments
in a request was 11, but with the introduction of indirect
descriptors the maximum number
IMHO there's no reason to set a m2p override if the mapping is done in
kernel space, so only set the m2p override when kmap_ops is set.
When kmap_ops is not set, just set the correct p2m translation, this
avoids touching the m2p lock, reducing contention around it.
Signed-off-by: Roger Pau Monné
Using __packed__ on the public interface is not correct, this
structures should be compiled using the native ABI, and __packed__
should only be used in the backend counterpart of those structures
(which needs to handle different ABIs).
This was even worse in the ARM case, where the Linux kernel
Add support for MSI message groups for Xen Dom0 using the
MAP_PIRQ_TYPE_MULTI_MSI pirq map type.
In order to keep track of which pirq is the first one in the group all
pirqs in the MSI group except for the first one have the newly
introduced PIRQ_MSI_GROUP flag set. This prevents calling
Add support for MSI message groups for Xen Dom0 using the
MAP_PIRQ_TYPE_MULTI_MSI pirq map type.
In order to keep track of which pirq is the first one in the group all
pirqs in the MSI group except for the first one have the newly
introduced PIRQ_MSI_GROUP flag set. This prevents calling
Allocate pending requests in smaller chunks instead of allocating them
all at the same time.
This change also removes the global array of pending_reqs, it is no
longer necessay.
Variables related to the grant mapping have been grouped into a struct
called grant_page, this allows to allocate them
With the introduction of indirect segments we can receive requests
with a number of segments bigger than the maximum number of allowed
iovecs in a bios, so make sure that blkback doesn't try to allocate a
bios with more iovecs than BIO_MAX_PAGES
Signed-off-by: Roger Pau Monné roger@citrix.com
Allocate pending requests in smaller chunks instead of allocating them
all at the same time.
This change also removes the global array of pending_reqs, it is no
longer necessay.
Variables related to the grant mapping have been grouped into a struct
called grant_page, this allows to allocate them
Allocate pending requests in smaller chunks instead of allocating them
all at the same time.
This change also removes the global array of pending_reqs, it is no
longer necessay.
Variables related to the grant mapping have been grouped into a struct
called grant_page, this allows to allocate them
When persistent grants were added they were always used, even if the
backend doesn't have this feature (there's no harm in always using the
same set of pages). This restores the old data path when the backend
doesn't have persistent grants, removing the burden of doing a memcpy
when it is not
The new GNTTABOP_unmap_and_duplicate operation doesn't zero the
mapping passed in new_addr, allowing us to perform batch unmaps in p2m
code without requiring the use of a multicall.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc:
Right now blkfront has no way to unmap grant refs, if using persistent
grants once a grant is used blkfront cannot assure if blkback will
have this grant mapped or not. To solve this problem, a new request
type (BLKIF_OP_UNMAP) that allows requesting blkback to unmap certain
grants is introduced.
With the current implementation, the callback in the tail of the list
can be added twice, because the check done in
gnttab_request_free_callback is bogus, callback-next can be NULL if
it is the last callback in the list. If we add the same callback twice
we end up with an infinite loop, were
Improve the calculation of required grants to process a request by
using nr_phys_segments instead of always assuming a request is going
to use all posible segments.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
The following patches prevent blkfront from hoarding all grants in the
system by allowing blkfront to request blkback to unmap certain grants
so they can be freed by blkfront. This is done periodically by
blkfront, unmapping a certain amount of unused persistent grants.
This series also
Prevent blkfront from hoarding all grants by adding a minimum number
of grants that must be free at all times. We still need a way to free
unused grants in blkfront, but this patch will mitigate the problem
in the meantime.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Konrad Rzeszutek
We are missing a check to see if the backend supports persistent
grants on resume, meaning we will always run with the value fetched
from the firsts host on which we run on.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: David Vrabel
This series contain blkback bug fixes for memory leaks (patches 1 and
2) and a race (patch 3). Patch 4 removes blkif_request_segment_aligned
since its memory layout is exactly the same as blkif_request_segment
and should introduce no functional change.
All patches should be backported to
I've at least identified two possible memory leaks in blkback, both
related to the shutdown path of a VBD:
- blkback doesn't wait for any pending purge work to finish before
cleaning the list of free_pages. The purge work will call
put_free_pages and thus we might end up with pages being
This was wrongly introduced in commit 402b27f9, the only difference
between blkif_request_segment_aligned and blkif_request_segment is
that the former has a named padding, while both share the same
memory layout.
Also correct a few minor glitches in the description, including for it
to no longer
From: Matt Rushton mrush...@amazon.com
Currently shrink_free_pagepool() is called before the pages used for
persistent grants are released via free_persistent_gnts(). This
results in a memory leak when a VBD that uses persistent grants is
torn down.
Cc: Konrad Rzeszutek Wilk
Introduce a new variable to keep track of the number of in-flight
requests. We need to make sure that when xen_blkif_put is called the
request has already been freed and we can safely free xen_blkif, which
was not the case before.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Konrad
I've at least identified two possible memory leaks in blkback, both
related to the shutdown path of a VBD:
- We don't wait for any pending purge work to finish before cleaning
the list of free_pages. The purge work will call put_free_pages and
thus we might end up with pages being added to
From: Matt Rushton mrush...@amazon.com
Currently shrink_free_pagepool() is called before the pages used for
persistent grants are released via free_persistent_gnts(). This
results in a memory leak when a VBD that uses persistent grants is
torn down.
Cc: Konrad Rzeszutek Wilk
Move the call to xen_blkif_put after we have freed the request,
otherwise we have a race between the release of the request and the
cleanup done in xen_blkif_free.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: David Vrabel
I've at least identified two possible memory leaks in blkback, both
related to the shutdown path of a VBD:
- blkback doesn't wait for any pending purge work to finish before
cleaning the list of free_pages. The purge work will call
put_free_pages and thus we might end up with pages being
blkback bug fixes for memory leaks (patches 1 and 2) and a race
(patch 3).
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
This series contains a couple of improvements to blkfront to make it
work better if there's a shortage on available free grants.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
There's no need to keep the foreign access in a grant if it is not
persistently mapped by the backend. This allows us to free grants that
are not mapped by the backend, thus preventing blkfront from hoarding
all grants.
The main effect of this is that blkfront will only persistently map
the same
Improve the calculation of required grants to process a request by
using nr_phys_segments instead of always assuming a request is going
to use all posible segments.
nr_phys_segments contains the number of scatter-gather DMA addr+len
pairs, which is basically what we put at every granted page.
Blkback cannot work properly on auto-translated guests if Xen doesn't
update the IOMMU when performing grant maps/unmaps, so only attach if
the newly introduced XENFEAT_hvm_gntmap_supports_iommu is found.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Konrad Rzeszutek Wilk
Current migration code uses blk_put_request in order to finish a request
before requeuing it. This function doesn't update the statistics of the
queue, which completely screws accounting. Use blk_end_request_all instead
which properly updates the statistics of the queue.
Signed-off-by: Roger Pau
I've done quite a lot of work in blkfront/blkback, and I usually end up
looking at the patches, so add myself as maintainer together with Konrad.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc:
1 - 100 of 285 matches
Mail list logo
