- Sep 25, 2020
-
-
Christoph Hellwig authored
Add a littler helper to make the somewhat arcane bd_contains checks a little more obvious. Signed-off-by:
Christoph Hellwig <hch@lst.de> Acked-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Christoph Hellwig authored
bd_contains is an implementation detail and should not be mentioned in a userspace API documentation. Signed-off-by:
-
Christoph Hellwig authored
Replace the two negative flags that are always used together with a single positive flag that indicates the writeback capability instead of two related non-capabilities. Also remove the pointless wrappers to just check the flag. Signed-off-by:
Jan Kara <jack@suse.cz> Reviewed-by:
Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by:
-
Christoph Hellwig authored
Replace BDI_CAP_NO_ACCT_WB with a positive BDI_CAP_WRITEBACK_ACCT to make the checks more obvious. Also remove the pointless bdi_cap_account_writeback wrapper that just obsfucates the check. Signed-off-by:
-
Christoph Hellwig authored
The BDI_CAP_STABLE_WRITES is one of the few bits of information in the backing_dev_info shared between the block drivers and the writeback code. To help untangling the dependency replace it with a queue flag and a superblock flag derived from it. This also helps with the case of e.g. a file system requiring stable writes due to its own checksumming, but not forcing it on other users of the block device like the swap code. One downside is that we an't support the stable_pages_required bdi attribute in sysfs anymore. It is replaced with a queue attribute which also is writable for easier testing. Signed-off-by:
-
Christoph Hellwig authored
There is no point in trying to call bdev_read_page if SWP_SYNCHRONOUS_IO is not set, as the device won't support it. Signed-off-by:
-
Christoph Hellwig authored
BDI_CAP_SYNCHRONOUS_IO is only checked in the swap code, and used to decided if ->rw_page can be used on a block device. Just check up for the method instead. The only complication is that zram needs a second set of block_device_operations as it can switch between modes that actually support ->rw_page and those who don't. Signed-off-by:
-
Christoph Hellwig authored
Just checking SB_I_CGROUPWB for cgroup writeback support is enough. Either the file system allocates its own bdi (e.g. btrfs), in which case it is known to support cgroup writeback, or the bdi comes from the block layer, which always supports cgroup writeback. Signed-off-by:
-
Christoph Hellwig authored
Drivers shouldn't really mess with the readahead size, as that is a VM concept. Instead set it based on the optimal I/O size by lifting the algorithm from the md driver when registering the disk. Also set bdi->io_pages there as well by applying the same scheme based on max_sectors. To ensure the limits work well for stacking drivers a new helper is added to update the readahead limits from the block limits, which is also called from disk_stack_limits. Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Reviewed-by:
Martin K. Petersen <martin.petersen@oracle.com> Acked-by:
Coly Li <colyli@suse.de> Signed-off-by:
-
Christoph Hellwig authored
The raid5 and raid10 drivers currently update the read-ahead size, but not the optimal I/O size on reshape. To prepare for deriving the read-ahead size from the optimal I/O size make sure it is updated as well. Signed-off-by:
Song Liu <song@kernel.org> Signed-off-by:
-
Christoph Hellwig authored
Set up a readahead size by default, as very few users have a good reason to change it. This means code, ecryptfs, and orangefs now set up the values while they were previously missing it, while ubifs, mtd and vboxsf manually set it to 0 to avoid readahead. Signed-off-by:
-
Christoph Hellwig authored
aoe forces a larger readahead size, but any reason to do larger I/O is not limited to readahead. Also set the optimal I/O size, and remove the local constants in favor of just using SZ_2G. Signed-off-by:
-
Christoph Hellwig authored
Inherit the optimal I/O size setting just like the readahead window, as any reason to do larger I/O does not apply to just readahead. Signed-off-by:
-
Christoph Hellwig authored
Ever since the switch to blk-mq, a lower device not used for VM writeback will not be marked congested, so the check will never trigger. Signed-off-by:
-
Christoph Hellwig authored
The last user of SB_I_MULTIROOT is disappeared with commit f2aedb71 ("NFS: Add fs_context support.") Signed-off-by:
-
- Sep 24, 2020
-
-
Christoph Hellwig authored
There are no users outside the core block code left now. Signed-off-by:
-
Christoph Hellwig authored
Use blkdev_get_by_dev instead of bdget + blkdev_get. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Christoph Hellwig authored
swap_type_of is used for two entirely different purposes: (1) check what swap type a given device/offset corresponds to (2) find the first available swap device that can be written to Mixing both in a single function creates an unreadable mess. Create two separate functions instead, and switch both to pass a dev_t instead of a struct block_device to further simplify the code. Signed-off-by:
-
Christoph Hellwig authored
Just check the dev_t to help simplifying the code. Signed-off-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
Christoph Hellwig authored
Use blkdev_get_by_dev instead of bdgrab + blkdev_get. Signed-off-by:
-
Christoph Hellwig authored
Use blkdev_get_by_dev instead of igrab (aka open coded bdgrab) + blkdev_get. Signed-off-by:
Joseph Qi <joseph.qi@linux.alibaba.com> Signed-off-by:
-
Christoph Hellwig authored
Use blkdev_get_by_dev instead of bdget_disk + blkdev_get. Signed-off-by:
Stefan Haberland <sth@linux.ibm.com> Signed-off-by:
-
Christoph Hellwig authored
Turn binding into a normal dev_t as the struct block device doesn't buy us anything and use blkdev_open_by_dev to actually open it. Signed-off-by:
-
Christoph Hellwig authored
Use blkdev_get_by_dev instead of bdgrab + blkdev_get. Signed-off-by:
-
Christoph Hellwig authored
Replace bdget + blkdev_get by blkdev_get_by_dev. Signed-off-by:
-
Christoph Hellwig authored
Remove code which has been dead since the initial commit. Signed-off-by:
-
Christoph Hellwig authored
Use blkdev_get_by_dev instead of bdgrab + blkdev_get. Signed-off-by:
-
Christoph Hellwig authored
Use blkdev_get_by_dev instead of open coding it using bdget_disk + blkdev_get, and split the code to read the partition table into a separate helper to make it a little more obvious. Signed-off-by:
-
Christoph Hellwig authored
We can only scan for partitions on the whole disk, so move the flag from struct block_device to struct gendisk. Signed-off-by:
-
Mike Snitzer authored
It is possible, albeit more unlikely, for a block device to have a non power-of-2 for chunk_sectors (e.g. 10+2 RAID6 with 128K chunk_sectors, which results in a full-stripe size of 1280K. This causes the RAID6's io_opt to be advertised as 1280K, and a stacked device _could_ then be made to use a blocksize, aka chunk_sectors, that matches non power-of-2 io_opt of underlying RAID6 -- resulting in stacked device's chunk_sectors being a non power-of-2). Update blk_queue_chunk_sectors() and blk_max_size_offset() to accommodate drivers that need a non power-of-2 chunk_sectors. Reviewed-by:
Ming Lei <ming.lei@redhat.com> Reviewed-by:
-
Mike Snitzer authored
Like 'io_opt', blk_stack_limits() should stack 'chunk_sectors' using lcm_not_zero() rather than min_not_zero() -- otherwise the final 'chunk_sectors' could result in sub-optimal alignment of IO to component devices in the IO stack. Also, if 'chunk_sectors' isn't a multiple of 'physical_block_size' then it is a bug in the driver and the device should be flagged as 'misaligned'. Reviewed-by:
-
- Sep 23, 2020
-
-
Christoph Hellwig authored
bmd is allocated using kmalloc in bio_alloc_map_data, so make sure is_null_mapped is properly initialized to false for the !null_mapped case. Fixes: f3256075 ("block: remove the BIO_NULL_MAPPED flag") Reported-by:
Marc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by:
-
Julia Lawall authored
sg_init_table zeroes its first argument, so the allocation of that argument doesn't have to. the semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/ ) // <smpl> @@ expression x; @@ x = - kzalloc + kmalloc (...) ... sg_init_table(x,...) // </smpl> Signed-off-by:
Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by:
-
- Sep 15, 2020
-
-
Baolin Wang authored
Do not need check the bps or iops limitation if bps or iops is unlimited. Signed-off-by:
Baolin Wang <baolin.wang@linux.alibaba.com> Signed-off-by:
-
Baolin Wang authored
The tg_may_dispatch() will call tg_with_in_bps_limit() and tg_with_in_iops_limit() to check if we can dispatch a bio or not, which will calculate bps/iops limitation multiple times. But tg_may_dispatch() is always called under queue lock, which means the bps/iops limitation will not change in tg_may_dispatch(). So we can calculate the bps/iops limitation only once, and pass them to tg_with_in_bps_limit() and tg_with_in_iops_limit() to avoid calculating bps/iops limitation repeatedly. Signed-off-by:
-
Baolin Wang authored
The 'throtl_grp_quantum' and 'throtl_quantum' are both read-only variables, thus better to use readable macros instead of static variables, which can also save some spaces for .bss area. Signed-off-by:
-
Baolin Wang authored
Use readable READ/WRITE macros instead of magic numbers. Signed-off-by:
-
Baolin Wang authored
Fix some comments' typos. Signed-off-by:
-
Tejun Heo authored
adjust_inuse_and_calc_cost() is responsible for reducing the amount of donated weights dynamically in period as the budget runs low. Because we don't want to do full donation calculation in period, we keep latching up inuse by INUSE_ADJ_STEP_PCT of the active weight of the cgroup until the resulting hweight_inuse is satisfactory. Unfortunately, the adj_step calculation was reading the active weight before acquiring ioc->lock. Because the current thread could have lost race to activate the iocg to another thread before entering this function, it may read the active weight as zero before acquiring ioc->lock. When this happens, the adj_step is calculated as zero and the incremental adjustment loop becomes an infinite one. Fix it by fetching the active weight after acquiring ioc->lock. Fixes: b0853ab4 ("blk-iocost: revamp in-period donation snapbacks") Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
- Sep 12, 2020
-
-
Tejun Heo authored
Conceptually, root_iocg->hweight_donating must be less than WEIGHT_ONE but all hweight calculations round up and thus it may end up >= WEIGHT_ONE triggering divide-by-zero and other issues. Bound the value to avoid surprises. Fixes: e08d02aa ("blk-iocost: implement Andy's method for donation weight updates") Signed-off-by:
-
