Changes in sysfs-driver-xen-blkback

e94c6101 - xen-blkback: Apply 'feature_persistent' parameter when connect

Fri, 15 Jul 2022 22:51:07 +0000

xen-blkback: Apply 'feature_persistent' parameter when connectIn some use cases[1], the backend is created while the frontend doesn'tsupport the persistent grants feature, but later the frontend can bechanged to support the feature and reconnect. In the past, 'blkback'enabled the persistent grants feature since it unconditionally checkedif frontend supports the persistent grants feature for every connect('connect_ring()') and decided whether it should use persistent grans ornot.However, commit aac8a70db24b ("xen-blkback: add a parameter fordisabling of persistent grants") has mistakenly changed the behavior.It made the frontend feature support check to not be repeated once itshown the 'feature_persistent' as 'false', or the frontend doesn'tsupport persistent grants.This commit changes the behavior of the parameter to make effect forevery connect, so that the previous workflow can work again as expected.[1] https://lore.kernel.org/xen-devel/CAJwUmVB6H3iTs-C+U=v-pwJB7-_ZRHPxHzKRJZ22xEPW7z8a=g@mail.gmail.com/Reported-by: Andrii Chepurnyi Fixes: aac8a70db24b ("xen-blkback: add a parameter for disabling of persistent grants")Cc: # 5.10.xSigned-off-by: Maximilian Heyne Signed-off-by: SeongJae Park Reviewed-by: Maximilian Heyne Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/20220715225108.193398-3-sj@kernel.orgSigned-off-by: Juergen Gross List of files: /linux-6.15/Documentation/ABI/testing/sysfs-driver-xen-blkback

12f112c3 - xen-blk{back,front}: Update contact points for buffer_squeeze_duration_ms and feature_persistent

Wed, 20 Apr 2022 07:27:34 +0000

xen-blk{back,front}: Update contact points for buffer_squeeze_duration_ms and feature_persistentSeongJae is currently listed as a contact point for some blk{back,front}features, but he will not work for XEN for a while. This committherefore updates the contact point to his colleague, Maximilian, who isunderstanding the context and actively working with the features now.Signed-off-by: SeongJae Park Signed-off-by: Maximilian Heyne Acked-by: Roger Pau Monné Link: https://lore.kernel.org/r/20220420072734.1692-1-sj@kernel.orgSigned-off-by: Juergen Gross List of files: /linux-6.15/Documentation/ABI/testing/sysfs-driver-xen-blkback

946c8fee - Documentation: Update SeongJae's email address

Fri, 17 Sep 2021 12:22:22 +0000

Documentation: Update SeongJae's email addressThis commit updates SeongJae's email addresses in documents to hispreferred one.Signed-off-by: SeongJae Park Link: https://lore.kernel.org/r/20210917122222.3109-1-sj@kernel.orgSigned-off-by: Jonathan Corbet List of files: /linux-6.15/Documentation/ABI/testing/sysfs-driver-xen-blkback

aac8a70d - xen-blkback: add a parameter for disabling of persistent grants

Wed, 23 Sep 2020 06:18:39 +0000

xen-blkback: add a parameter for disabling of persistent grantsPersistent grants feature provides high scalability. On some smallsystems, however, it could incur data copy overheads[1] and thus it isrequired to be disabled. But, there is no option to disable it. Forthe reason, this commit adds a module parameter for disabling of thefeature.[1] https://wiki.xen.org/wiki/Xen_4.3_Block_Protocol_ScalabilitySigned-off-by: Anthony Liguori Signed-off-by: SeongJae Park Reviewed-by: Juergen Gross Acked-by: Roger Pau Monné Link: https://lore.kernel.org/r/20200923061841.20531-2-sjpark@amazon.comSigned-off-by: Boris Ostrovsky List of files: /linux-6.15/Documentation/ABI/testing/sysfs-driver-xen-blkback

cb9369bd - xen/blkback: Squeeze page pools if a memory pressure is detected

Mon, 27 Jan 2020 08:18:10 +0000

xen/blkback: Squeeze page pools if a memory pressure is detectedEach `blkif` has a free pages pool for the grant mapping. The size ofthe pool starts from zero and is increased on demand while processingthe I/O requests. If current I/O requests handling is finished or 100milliseconds has passed since last I/O requests handling, it checks andshrinks the pool to not exceed the size limit, `max_buffer_pages`.Therefore, host administrators can cause memory pressure in blkback byattaching a large number of block devices and inducing I/O. Suchproblematic situations can be avoided by limiting the maximum number ofdevices that can be attached, but finding the optimal limit is not soeasy. Improper set of the limit can results in memory pressure or aresource underutilization. This commit avoids such problematicsituations by squeezing the pools (returns every free page in the poolto the system) for a while (users can set this duration via a moduleparameter) if memory pressure is detected.Discussions===========The `blkback`'s original shrinking mechanism returns only pages in thepool which are not currently be used by `blkback` to the system. Inother words, the pages that are not mapped with granted pages. Becausethis commit is changing only the shrink limit but still uses the samefreeing mechanism it does not touch pages which are currently mappinggrants.Once memory pressure is detected, this commit keeps the squeezing limitfor a user-specified time duration. The duration should be neither toolong nor too short. If it is too long, the squeezing incurring overheadcan reduce the I/O performance. If it is too short, `blkback` will notfree enough pages to reduce the memory pressure. This commit sets thevalue as `10 milliseconds` by default because it is a short time interms 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 100milliseconds, this could be a somewhat reasonable choice. I also testedother durations (refer to the below section for more details) andconfirmed that 10 milliseconds is the one that works best with the test.That said, the proper duration depends on actual configurations andworkloads. That's why this commit allows users to set the duration as amodule parameter.Memory Pressure Test====================To show how this commit fixes the memory pressure situation well, Iconfigured a test environment on a xen-running virtualization system.On the `blkfront` running guest instances, I attach a large number ofnetwork-backed volume devices and induce I/O to those. Meanwhile, Imeasure 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. Asshown below, this commit has dramatically reduced the memory pressure: pswpin pswpout before 76,672 185,799 after 867 3,967Optimal Aggressive Shrinking Duration-------------------------------------To find a best squeezing duration, I repeated the test with threedifferent durations (1ms, 10ms, and 100ms). The results are as below: duration pswpin pswpout 1 707 5,095 10 867 3,967 100 362 3,348As expected, the memory pressure decreases as the duration increases,but the reduction become slow from the `10ms`. Based on this results, Ichose the default duration as 10ms.Performance Overhead Test=========================This commit could incur I/O performance degradation under severe memorypressure because the squeezing will require more page allocations perI/O. To show the overhead, I artificially made a worst-case squeezingsituation and measured the I/O performance of a `blkfront` runningguest.For the artificial squeezing, I set the `blkback.max_buffer_pages` usingthe `/sys/module/xen_blkback/parameters/max_buffer_pages` file. In thistest, I set the value to `1024` and `0`. The `1024` is the defaultvalue. Setting the value as `0` is same to a situation doing thesqueezing always (worst-case).If the underlying block device is slow enough, the squeezing overheadcould be hidden. For the reason, I use a fast block device, namely therbd[1]: # xl block-attach guest phy:/dev/ram0 xvdb wFor the I/O performance measurement, I run a simple `dd` command 5 timesdirectly 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; doneThe 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% confidenceIn short, even worst case squeezing on ramdisk based fast block devicemakes no visible performance degradation. Please note that this is justa very simple and minimal test. On systems using super-fast blockdevices and a special I/O workload, the results might be different. Ifyou have any doubt, test on your machine with your workload to find theoptimal squeezing duration for you.[1] https://www.kernel.org/doc/html/latest/admin-guide/blockdev/ramdisk.htmlReviewed-by: Roger Pau Monné Signed-off-by: SeongJae Park Signed-off-by: Boris Ostrovsky List of files: /linux-6.15/Documentation/ABI/testing/sysfs-driver-xen-blkback

973e5405 - xen/blkback: don't keep persistent grants too long

Mon, 13 Aug 2018 14:01:10 +0000

xen/blkback: don't keep persistent grants too longPersistent grants are allocated until a threshold per ring is beingreached. Those grants won't be freed until the ring is being destroyedmeaning there will be resources kept busy which might no longer beused.Instead of freeing only persistent grants until the threshold isreached add a timestamp and remove all persistent grants not havingbeen in use for a minute.Signed-off-by: Juergen Gross Reviewed-by: Roger Pau Monné Signed-off-by: Konrad Rzeszutek Wilk List of files: /linux-6.15/Documentation/ABI/testing/sysfs-driver-xen-blkback

1d199650 - xen-blkback/sysfs: Move the parameters for the persistent grant features

Tue, 04 Jun 2013 13:32:41 +0000

xen-blkback/sysfs: Move the parameters for the persistent grant featuresto a testing subdirectory (as this value should not be bakedfor the life-time) and also in an appropiate file.Also modified the introduction Linux version from 3.10 to 3.11.Signed-off-by: Konrad Rzeszutek Wilk List of files: /linux-6.15/Documentation/ABI/testing/sysfs-driver-xen-blkback