| Message ID | 20191216124527.30306-3-sjpark@amazon.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | xenbus/backend: Add a memory pressure handler callback | expand |
On Mon, 16 Dec 2019 13:45:25 +0100 SeongJae Park <sjpark@amazon.com> wrote: > From: SeongJae Park <sjpark@amazon.de> > > Each `blkif` has a free pages pool for the grant mapping. The size of > the pool starts from zero and is increased on demand while processing > the I/O requests. If current I/O requests handling is finished or 100 > milliseconds has passed since last I/O requests handling, it checks and > shrinks the pool to not exceed the size limit, `max_buffer_pages`. > > Therefore, host administrators can cause memory pressure in blkback by > attaching a large number of block devices and inducing I/O. Such > problematic situations can be avoided by limiting the maximum number of > devices that can be attached, but finding the optimal limit is not so > easy. Improper set of the limit can results in memory pressure or a > resource underutilization. This commit avoids such problematic > situations by squeezing the pools (returns every free page in the pool > to the system) for a while (users can set this duration via a module > parameter) if memory pressure is detected. > > Discussions > =========== > > The `blkback`'s original shrinking mechanism returns only pages in the > pool which are not currently be used by `blkback` to the system. In > other words, the pages that are not mapped with granted pages. Because > this commit is changing only the shrink limit but still uses the same > freeing mechanism it does not touch pages which are currently mapping > grants. > > Once memory pressure is detected, this commit keeps the squeezing limit > for a user-specified time duration. The duration should be neither too > long nor too short. If it is too long, the squeezing incurring overhead > can reduce the I/O performance. If it is too short, `blkback` will not > free enough pages to reduce the memory pressure. This commit sets the > value as `10 milliseconds` by default because it is a short time in > terms of I/O while it is a long time in terms of memory operations. > Also, as the original shrinking mechanism works for at least every 100 > milliseconds, this could be a somewhat reasonable choice. I also tested > other durations (refer to the below section for more details) and > confirmed that 10 milliseconds is the one that works best with the test. > That said, the proper duration depends on actual configurations and > workloads. That's why this commit allows users to set the duration as a > module parameter. > > Memory Pressure Test > ==================== > > To show how this commit fixes the memory pressure situation well, I > configured a test environment on a xen-running virtualization system. > On the `blkfront` running guest instances, I attach a large number of > network-backed volume devices and induce I/O to those. Meanwhile, I > measure the number of pages that swapped in (pswpin) and out (pswpout) > on the `blkback` running guest. The test ran twice, once for the > `blkback` before this commit and once for that after this commit. As > shown below, this commit has dramatically reduced the memory pressure: > > pswpin pswpout > before 76,672 185,799 > after 212 3,325 > > Optimal Aggressive Shrinking Duration > ------------------------------------- > > To find a best squeezing duration, I repeated the test with three > different durations (1ms, 10ms, and 100ms). The results are as below: > > duration pswpin pswpout > 1 852 6,424 > 10 212 3,325 > 100 203 3,340 > > As expected, the memory pressure has decreased as the duration is > increased, but the reduction stopped from the `10ms`. Based on this > results, I chose the default duration as 10ms. > > Performance Overhead Test > ========================= > > This commit could incur I/O performance degradation under severe memory > pressure because the squeezing will require more page allocations per > I/O. To show the overhead, I artificially made a worst-case squeezing > situation and measured the I/O performance of a `blkfront` running > guest. > > For the artificial squeezing, I set the `blkback.max_buffer_pages` using > the `/sys/module/xen_blkback/parameters/max_buffer_pages` file. In this > test, I set the value to `1024` and `0`. The `1024` is the default > value. Setting the value as `0` is same to a situation doing the > squeezing always (worst-case). > > If the underlying block device is slow enough, the squeezing overhead > could be hidden. For the reason, I use a fast block device, namely the > rbd[1]: > > # xl block-attach guest phy:/dev/ram0 xvdb w > > For the I/O performance measurement, I run a simple `dd` command 5 times > directly to the device as below and collect the 'MB/s' results. > > $ for i in {1..5}; do dd if=/dev/zero of=/dev/xvdb \ > bs=4k count=$((256*512)); sync; done > > The results are as below. 'max_pgs' represents the value of the > `blkback.max_buffer_pages` parameter. > > max_pgs Min Max Median Avg Stddev > 0 417 423 420 419.4 2.5099801 > 1024 414 425 416 417.8 4.4384682 > No difference proven at 95.0% confidence > > In short, even worst case squeezing on ramdisk based fast block device > makes no visible performance degradation. Please note that this is just > a very simple and minimal test. On systems using super-fast block > devices and a special I/O workload, the results might be different. If > you have any doubt, test on your machine with your workload to find the > optimal squeezing duration for you. > > [1] https://www.kernel.org/doc/html/latest/admin-guide/blockdev/ramdisk.html > > Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> > Signed-off-by: SeongJae Park <sjpark@amazon.de> > --- > .../ABI/testing/sysfs-driver-xen-blkback | 10 +++++++++ > drivers/block/xen-blkback/blkback.c | 7 +++++-- > drivers/block/xen-blkback/common.h | 1 + > drivers/block/xen-blkback/xenbus.c | 21 ++++++++++++++++++- > 4 files changed, 36 insertions(+), 3 deletions(-) > > diff --git a/Documentation/ABI/testing/sysfs-driver-xen-blkback b/Documentation/ABI/testing/sysfs-driver-xen-blkback > index 4e7babb3ba1f..f01224231f3f 100644 > --- a/Documentation/ABI/testing/sysfs-driver-xen-blkback > +++ b/Documentation/ABI/testing/sysfs-driver-xen-blkback > @@ -25,3 +25,13 @@ Description: > allocated without being in use. The time is in > seconds, 0 means indefinitely long. > The default is 60 seconds. > + > +What: /sys/module/xen_blkback/parameters/buffer_squeeze_duration_ms > +Date: December 2019 > +KernelVersion: 5.5 > +Contact: SeongJae Park <sjpark@amazon.de> > +Description: > + When memory pressure is reported to blkback this option > + controls the duration in milliseconds that blkback will not > + cache any page not backed by a grant mapping. > + The default is 10ms. > diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c > index fd1e19f1a49f..79f677aeb5cc 100644 > --- a/drivers/block/xen-blkback/blkback.c > +++ b/drivers/block/xen-blkback/blkback.c > @@ -656,8 +656,11 @@ int xen_blkif_schedule(void *arg) > ring->next_lru = jiffies + msecs_to_jiffies(LRU_INTERVAL); > } > > - /* Shrink if we have more than xen_blkif_max_buffer_pages */ > - shrink_free_pagepool(ring, xen_blkif_max_buffer_pages); > + /* Shrink the free pages pool if it is too large. */ > + if (time_before(jiffies, blkif->buffer_squeeze_end)) > + shrink_free_pagepool(ring, 0); > + else > + shrink_free_pagepool(ring, xen_blkif_max_buffer_pages); > > if (log_stats && time_after(jiffies, ring->st_print)) > print_stats(ring); > diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h > index 1d3002d773f7..536c84f61fed 100644 > --- a/drivers/block/xen-blkback/common.h > +++ b/drivers/block/xen-blkback/common.h > @@ -319,6 +319,7 @@ struct xen_blkif { > /* All rings for this device. */ > struct xen_blkif_ring *rings; > unsigned int nr_rings; > + unsigned long buffer_squeeze_end; > }; > > struct seg_buf { > diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c > index b90dbcd99c03..4f6ea4feca79 100644 > --- a/drivers/block/xen-blkback/xenbus.c > +++ b/drivers/block/xen-blkback/xenbus.c > @@ -824,6 +824,24 @@ static void frontend_changed(struct xenbus_device *dev, > } > > > +/* Once a memory pressure is detected, squeeze free page pools for a while. */ > +static unsigned int buffer_squeeze_duration_ms = 10; > +module_param_named(buffer_squeeze_duration_ms, > + buffer_squeeze_duration_ms, int, 0644); > +MODULE_PARM_DESC(buffer_squeeze_duration_ms, > +"Duration in ms to squeeze pages buffer when a memory pressure is detected"); > + > +/* > + * Callback received when the memory pressure is detected. > + */ > +static void reclaim_memory(struct xenbus_device *dev) > +{ > + struct backend_info *be = dev_get_drvdata(&dev->dev); > + > + be->blkif->buffer_squeeze_end = jiffies + > + msecs_to_jiffies(buffer_squeeze_duration_ms); This callback might race with 'xen_blkbk_probe()'. The race could result in __NULL dereferencing__, as 'xen_blkbk_probe()' sets '->blkif' after it links 'be' to the 'dev'. Please _don't merge_ this patch now! I will do more test and share results. Meanwhile, if you have any opinion, please let me know. Thanks, SeongJae Park > +} > + > /* ** Connection ** */ > > > @@ -1115,7 +1133,8 @@ static struct xenbus_driver xen_blkbk_driver = { > .ids = xen_blkbk_ids, > .probe = xen_blkbk_probe, > .remove = xen_blkbk_remove, > - .otherend_changed = frontend_changed > + .otherend_changed = frontend_changed, > + .reclaim_memory = reclaim_memory, > }; > > int xen_blkif_xenbus_init(void) > -- > 2.17.1 >
On Mon, 16 Dec 2019 15:37:20 +0100 SeongJae Park <sjpark@amazon.com> wrote: > On Mon, 16 Dec 2019 13:45:25 +0100 SeongJae Park <sjpark@amazon.com> wrote: > > > From: SeongJae Park <sjpark@amazon.de> > > [...] > > --- a/drivers/block/xen-blkback/xenbus.c > > +++ b/drivers/block/xen-blkback/xenbus.c > > @@ -824,6 +824,24 @@ static void frontend_changed(struct xenbus_device *dev, > > } > > > > > > +/* Once a memory pressure is detected, squeeze free page pools for a while. */ > > +static unsigned int buffer_squeeze_duration_ms = 10; > > +module_param_named(buffer_squeeze_duration_ms, > > + buffer_squeeze_duration_ms, int, 0644); > > +MODULE_PARM_DESC(buffer_squeeze_duration_ms, > > +"Duration in ms to squeeze pages buffer when a memory pressure is detected"); > > + > > +/* > > + * Callback received when the memory pressure is detected. > > + */ > > +static void reclaim_memory(struct xenbus_device *dev) > > +{ > > + struct backend_info *be = dev_get_drvdata(&dev->dev); > > + > > + be->blkif->buffer_squeeze_end = jiffies + > > + msecs_to_jiffies(buffer_squeeze_duration_ms); > > This callback might race with 'xen_blkbk_probe()'. The race could result in > __NULL dereferencing__, as 'xen_blkbk_probe()' sets '->blkif' after it links > 'be' to the 'dev'. Please _don't merge_ this patch now! > > I will do more test and share results. Meanwhile, if you have any opinion, > please let me know. Not only '->blkif', but 'be' itself also coule be a NULL. As similar concurrency issues could be in other drivers in their way, I suggest to change the reclaim callback ('->reclaim_memory') to be called for each driver instead of each device. Then, each driver could be able to deal with its concurrency issues by itself. For blkback, we could reuse the global variable based approach, as similar to the v7[1] of this patchset. As the callback is called for each driver instead of each device now, the duplicated set of the timeout will not happen. Thanks, SeongJae Park [1] https://lore.kernel.org/xen-devel/20191211181016.14366-1-sjpark@amazon.de/ > > > Thanks, > SeongJae Park > > > +} > > + > > /* ** Connection ** */ > > > > > > @@ -1115,7 +1133,8 @@ static struct xenbus_driver xen_blkbk_driver = { > > .ids = xen_blkbk_ids, > > .probe = xen_blkbk_probe, > > .remove = xen_blkbk_remove, > > - .otherend_changed = frontend_changed > > + .otherend_changed = frontend_changed, > > + .reclaim_memory = reclaim_memory, > > }; > > > > int xen_blkif_xenbus_init(void) > > -- > > 2.17.1 > > >
On 16.12.19 17:15, SeongJae Park wrote: > On Mon, 16 Dec 2019 15:37:20 +0100 SeongJae Park <sjpark@amazon.com> wrote: > >> On Mon, 16 Dec 2019 13:45:25 +0100 SeongJae Park <sjpark@amazon.com> wrote: >> >>> From: SeongJae Park <sjpark@amazon.de> >>> > [...] >>> --- a/drivers/block/xen-blkback/xenbus.c >>> +++ b/drivers/block/xen-blkback/xenbus.c >>> @@ -824,6 +824,24 @@ static void frontend_changed(struct xenbus_device *dev, >>> } >>> >>> >>> +/* Once a memory pressure is detected, squeeze free page pools for a while. */ >>> +static unsigned int buffer_squeeze_duration_ms = 10; >>> +module_param_named(buffer_squeeze_duration_ms, >>> + buffer_squeeze_duration_ms, int, 0644); >>> +MODULE_PARM_DESC(buffer_squeeze_duration_ms, >>> +"Duration in ms to squeeze pages buffer when a memory pressure is detected"); >>> + >>> +/* >>> + * Callback received when the memory pressure is detected. >>> + */ >>> +static void reclaim_memory(struct xenbus_device *dev) >>> +{ >>> + struct backend_info *be = dev_get_drvdata(&dev->dev); >>> + >>> + be->blkif->buffer_squeeze_end = jiffies + >>> + msecs_to_jiffies(buffer_squeeze_duration_ms); >> >> This callback might race with 'xen_blkbk_probe()'. The race could result in >> __NULL dereferencing__, as 'xen_blkbk_probe()' sets '->blkif' after it links >> 'be' to the 'dev'. Please _don't merge_ this patch now! >> >> I will do more test and share results. Meanwhile, if you have any opinion, >> please let me know. > > Not only '->blkif', but 'be' itself also coule be a NULL. As similar > concurrency issues could be in other drivers in their way, I suggest to change > the reclaim callback ('->reclaim_memory') to be called for each driver instead > of each device. Then, each driver could be able to deal with its concurrency > issues by itself. Hmm, I don't like that. This would need to be changed back in case we add per-guest quota. Wouldn't a get_device() before calling the callback and a put_device() afterwards avoid that problem? Juergen
On on, 16 Dec 2019 17:23:44 +0100, Jürgen Groß wrote: > On 16.12.19 17:15, SeongJae Park wrote: > > On Mon, 16 Dec 2019 15:37:20 +0100 SeongJae Park <sjpark@amazon.com> wrote: > > > >> On Mon, 16 Dec 2019 13:45:25 +0100 SeongJae Park <sjpark@amazon.com> wrote: > >> > >>> From: SeongJae Park <sjpark@amazon.de> > >>> > > [...] > >>> --- a/drivers/block/xen-blkback/xenbus.c > >>> +++ b/drivers/block/xen-blkback/xenbus.c > >>> @@ -824,6 +824,24 @@ static void frontend_changed(struct xenbus_device *dev, > >>> } > >>> > >>> > >>> +/* Once a memory pressure is detected, squeeze free page pools for a while. */ > >>> +static unsigned int buffer_squeeze_duration_ms = 10; > >>> +module_param_named(buffer_squeeze_duration_ms, > >>> + buffer_squeeze_duration_ms, int, 0644); > >>> +MODULE_PARM_DESC(buffer_squeeze_duration_ms, > >>> +"Duration in ms to squeeze pages buffer when a memory pressure is detected"); > >>> + > >>> +/* > >>> + * Callback received when the memory pressure is detected. > >>> + */ > >>> +static void reclaim_memory(struct xenbus_device *dev) > >>> +{ > >>> + struct backend_info *be = dev_get_drvdata(&dev->dev); > >>> + > >>> + be->blkif->buffer_squeeze_end = jiffies + > >>> + msecs_to_jiffies(buffer_squeeze_duration_ms); > >> > >> This callback might race with 'xen_blkbk_probe()'. The race could result in > >> __NULL dereferencing__, as 'xen_blkbk_probe()' sets '->blkif' after it links > >> 'be' to the 'dev'. Please _don't merge_ this patch now! > >> > >> I will do more test and share results. Meanwhile, if you have any opinion, > >> please let me know. I reduced system memory and attached bunch of devices in short time so that memory pressure occurs while device attachments are ongoing. Under this circumstance, I was able to see the race. > > > > Not only '->blkif', but 'be' itself also coule be a NULL. As similar > > concurrency issues could be in other drivers in their way, I suggest to change > > the reclaim callback ('->reclaim_memory') to be called for each driver instead > > of each device. Then, each driver could be able to deal with its concurrency > > issues by itself. > > Hmm, I don't like that. This would need to be changed back in case we > add per-guest quota. Extending this callback in that way would be still not too hard. We could use the argument to the callback. I would keep the argument of the callback to 'struct device *' as is, and will add a comment saying 'NULL' value of the argument means every devices. As an example, xenbus would pass NULL-ending array of the device pointers that need to free its resources. After seeing this race, I am now also thinking it could be better to delegate detailed control of each device to its driver, as some drivers have some complicated and unique relation with its devices. > > Wouldn't a get_device() before calling the callback and a put_device() > afterwards avoid that problem? I didn't used the reference count manipulation operations because other similar parts also didn't. But, if there is no implicit reference count guarantee, it seems those operations are indeed necessary. That said, as get/put operations only adjust the reference count, those will not make the callback to wait until the linking of the 'backend' and 'blkif' to the device (xen_blkbk_probe()) is finished. Thus, the race could still happen. Or, am I missing something? I also modified the code to do 'get_device()' and 'put_device()' as you suggested and did test, but the race was still reproducible. Thanks, SeongJae Park > > > Juergen
On 16.12.19 20:48, SeongJae Park wrote: > On on, 16 Dec 2019 17:23:44 +0100, Jürgen Groß wrote: > >> On 16.12.19 17:15, SeongJae Park wrote: >>> On Mon, 16 Dec 2019 15:37:20 +0100 SeongJae Park <sjpark@amazon.com> wrote: >>> >>>> On Mon, 16 Dec 2019 13:45:25 +0100 SeongJae Park <sjpark@amazon.com> wrote: >>>> >>>>> From: SeongJae Park <sjpark@amazon.de> >>>>> >>> [...] >>>>> --- a/drivers/block/xen-blkback/xenbus.c >>>>> +++ b/drivers/block/xen-blkback/xenbus.c >>>>> @@ -824,6 +824,24 @@ static void frontend_changed(struct xenbus_device *dev, >>>>> } >>>>> >>>>> >>>>> +/* Once a memory pressure is detected, squeeze free page pools for a while. */ >>>>> +static unsigned int buffer_squeeze_duration_ms = 10; >>>>> +module_param_named(buffer_squeeze_duration_ms, >>>>> + buffer_squeeze_duration_ms, int, 0644); >>>>> +MODULE_PARM_DESC(buffer_squeeze_duration_ms, >>>>> +"Duration in ms to squeeze pages buffer when a memory pressure is detected"); >>>>> + >>>>> +/* >>>>> + * Callback received when the memory pressure is detected. >>>>> + */ >>>>> +static void reclaim_memory(struct xenbus_device *dev) >>>>> +{ >>>>> + struct backend_info *be = dev_get_drvdata(&dev->dev); >>>>> + >>>>> + be->blkif->buffer_squeeze_end = jiffies + >>>>> + msecs_to_jiffies(buffer_squeeze_duration_ms); >>>> >>>> This callback might race with 'xen_blkbk_probe()'. The race could result in >>>> __NULL dereferencing__, as 'xen_blkbk_probe()' sets '->blkif' after it links >>>> 'be' to the 'dev'. Please _don't merge_ this patch now! >>>> >>>> I will do more test and share results. Meanwhile, if you have any opinion, >>>> please let me know. > > I reduced system memory and attached bunch of devices in short time so that > memory pressure occurs while device attachments are ongoing. Under this > circumstance, I was able to see the race. > >>> >>> Not only '->blkif', but 'be' itself also coule be a NULL. As similar >>> concurrency issues could be in other drivers in their way, I suggest to change >>> the reclaim callback ('->reclaim_memory') to be called for each driver instead >>> of each device. Then, each driver could be able to deal with its concurrency >>> issues by itself. >> >> Hmm, I don't like that. This would need to be changed back in case we >> add per-guest quota. > > Extending this callback in that way would be still not too hard. We could use > the argument to the callback. I would keep the argument of the callback to > 'struct device *' as is, and will add a comment saying 'NULL' value of the > argument means every devices. As an example, xenbus would pass NULL-ending > array of the device pointers that need to free its resources. > > After seeing this race, I am now also thinking it could be better to delegate > detailed control of each device to its driver, as some drivers have some > complicated and unique relation with its devices. > >> >> Wouldn't a get_device() before calling the callback and a put_device() >> afterwards avoid that problem? > > I didn't used the reference count manipulation operations because other similar > parts also didn't. But, if there is no implicit reference count guarantee, it > seems those operations are indeed necessary. > > That said, as get/put operations only adjust the reference count, those will > not make the callback to wait until the linking of the 'backend' and 'blkif' to > the device (xen_blkbk_probe()) is finished. Thus, the race could still happen. > Or, am I missing something? No, I think we need a xenbus lock per device which will need to be taken in xen_blkbk_probe(), xenbus_dev_remove() and while calling the callback. Juergen
On Mon, Dec 16, 2019 at 08:48:03PM +0100, SeongJae Park wrote: > On on, 16 Dec 2019 17:23:44 +0100, Jürgen Groß wrote: > > > On 16.12.19 17:15, SeongJae Park wrote: > > > On Mon, 16 Dec 2019 15:37:20 +0100 SeongJae Park <sjpark@amazon.com> wrote: > > > > > >> On Mon, 16 Dec 2019 13:45:25 +0100 SeongJae Park <sjpark@amazon.com> wrote: > > >> > > >>> From: SeongJae Park <sjpark@amazon.de> > > >>> > > > [...] > > >>> --- a/drivers/block/xen-blkback/xenbus.c > > >>> +++ b/drivers/block/xen-blkback/xenbus.c > > >>> @@ -824,6 +824,24 @@ static void frontend_changed(struct xenbus_device *dev, > > >>> } > > >>> > > >>> > > >>> +/* Once a memory pressure is detected, squeeze free page pools for a while. */ > > >>> +static unsigned int buffer_squeeze_duration_ms = 10; > > >>> +module_param_named(buffer_squeeze_duration_ms, > > >>> + buffer_squeeze_duration_ms, int, 0644); > > >>> +MODULE_PARM_DESC(buffer_squeeze_duration_ms, > > >>> +"Duration in ms to squeeze pages buffer when a memory pressure is detected"); > > >>> + > > >>> +/* > > >>> + * Callback received when the memory pressure is detected. > > >>> + */ > > >>> +static void reclaim_memory(struct xenbus_device *dev) > > >>> +{ > > >>> + struct backend_info *be = dev_get_drvdata(&dev->dev); > > >>> + > > >>> + be->blkif->buffer_squeeze_end = jiffies + > > >>> + msecs_to_jiffies(buffer_squeeze_duration_ms); > > >> > > >> This callback might race with 'xen_blkbk_probe()'. The race could result in > > >> __NULL dereferencing__, as 'xen_blkbk_probe()' sets '->blkif' after it links > > >> 'be' to the 'dev'. Please _don't merge_ this patch now! > > >> > > >> I will do more test and share results. Meanwhile, if you have any opinion, > > >> please let me know. > > I reduced system memory and attached bunch of devices in short time so that > memory pressure occurs while device attachments are ongoing. Under this > circumstance, I was able to see the race. > > > > > > > Not only '->blkif', but 'be' itself also coule be a NULL. As similar > > > concurrency issues could be in other drivers in their way, I suggest to change > > > the reclaim callback ('->reclaim_memory') to be called for each driver instead > > > of each device. Then, each driver could be able to deal with its concurrency > > > issues by itself. > > > > Hmm, I don't like that. This would need to be changed back in case we > > add per-guest quota. > > Extending this callback in that way would be still not too hard. We could use > the argument to the callback. I would keep the argument of the callback to > 'struct device *' as is, and will add a comment saying 'NULL' value of the > argument means every devices. As an example, xenbus would pass NULL-ending > array of the device pointers that need to free its resources. > > After seeing this race, I am now also thinking it could be better to delegate > detailed control of each device to its driver, as some drivers have some > complicated and unique relation with its devices. > > > > > Wouldn't a get_device() before calling the callback and a put_device() > > afterwards avoid that problem? > > I didn't used the reference count manipulation operations because other similar > parts also didn't. But, if there is no implicit reference count guarantee, it > seems those operations are indeed necessary. > > That said, as get/put operations only adjust the reference count, those will > not make the callback to wait until the linking of the 'backend' and 'blkif' to > the device (xen_blkbk_probe()) is finished. Thus, the race could still happen. > Or, am I missing something? I would expect the device is not added to the list of backend devices until the probe hook has finished with a non-error return code. Ie: bus_for_each_dev should _not_ iterate over devices for which the probe function hasn't been run to competition without errors. The same way I would expect the remove hook to first remove the device from the list of backend devices and then run the remove hook. blkback uses an ad-hoc reference counting mechanism, but if the above assumptions are true I think it would be enough to take an extra reference in xen_blkbk_probe and drop it in xen_blkbk_remove. Additionally it might be interesting to switch the ad-hoc reference counting to use get_device/put_device (in a separate patch), but I'm not sure how feasible that is. Roger.
diff --git a/Documentation/ABI/testing/sysfs-driver-xen-blkback b/Documentation/ABI/testing/sysfs-driver-xen-blkback index 4e7babb3ba1f..f01224231f3f 100644 --- a/Documentation/ABI/testing/sysfs-driver-xen-blkback +++ b/Documentation/ABI/testing/sysfs-driver-xen-blkback @@ -25,3 +25,13 @@ Description: allocated without being in use. The time is in seconds, 0 means indefinitely long. The default is 60 seconds. + +What: /sys/module/xen_blkback/parameters/buffer_squeeze_duration_ms +Date: December 2019 +KernelVersion: 5.5 +Contact: SeongJae Park <sjpark@amazon.de> +Description: + When memory pressure is reported to blkback this option + controls the duration in milliseconds that blkback will not + cache any page not backed by a grant mapping. + The default is 10ms. diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c index fd1e19f1a49f..79f677aeb5cc 100644 --- a/drivers/block/xen-blkback/blkback.c +++ b/drivers/block/xen-blkback/blkback.c @@ -656,8 +656,11 @@ int xen_blkif_schedule(void *arg) ring->next_lru = jiffies + msecs_to_jiffies(LRU_INTERVAL); } - /* Shrink if we have more than xen_blkif_max_buffer_pages */ - shrink_free_pagepool(ring, xen_blkif_max_buffer_pages); + /* Shrink the free pages pool if it is too large. */ + if (time_before(jiffies, blkif->buffer_squeeze_end)) + shrink_free_pagepool(ring, 0); + else + shrink_free_pagepool(ring, xen_blkif_max_buffer_pages); if (log_stats && time_after(jiffies, ring->st_print)) print_stats(ring); diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h index 1d3002d773f7..536c84f61fed 100644 --- a/drivers/block/xen-blkback/common.h +++ b/drivers/block/xen-blkback/common.h @@ -319,6 +319,7 @@ struct xen_blkif { /* All rings for this device. */ struct xen_blkif_ring *rings; unsigned int nr_rings; + unsigned long buffer_squeeze_end; }; struct seg_buf { diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c index b90dbcd99c03..4f6ea4feca79 100644 --- a/drivers/block/xen-blkback/xenbus.c +++ b/drivers/block/xen-blkback/xenbus.c @@ -824,6 +824,24 @@ static void frontend_changed(struct xenbus_device *dev, } +/* Once a memory pressure is detected, squeeze free page pools for a while. */ +static unsigned int buffer_squeeze_duration_ms = 10; +module_param_named(buffer_squeeze_duration_ms, + buffer_squeeze_duration_ms, int, 0644); +MODULE_PARM_DESC(buffer_squeeze_duration_ms, +"Duration in ms to squeeze pages buffer when a memory pressure is detected"); + +/* + * Callback received when the memory pressure is detected. + */ +static void reclaim_memory(struct xenbus_device *dev) +{ + struct backend_info *be = dev_get_drvdata(&dev->dev); + + be->blkif->buffer_squeeze_end = jiffies + + msecs_to_jiffies(buffer_squeeze_duration_ms); +} + /* ** Connection ** */ @@ -1115,7 +1133,8 @@ static struct xenbus_driver xen_blkbk_driver = { .ids = xen_blkbk_ids, .probe = xen_blkbk_probe, .remove = xen_blkbk_remove, - .otherend_changed = frontend_changed + .otherend_changed = frontend_changed, + .reclaim_memory = reclaim_memory, }; int xen_blkif_xenbus_init(void)