Re: Commit edf064e7c (btrfs: nowait aio support) breaks shells
On 2017.07.04 at 10:31 -0500, Goldwyn Rodrigues wrote: > > > On 07/04/2017 02:45 AM, Markus Trippelsdorf wrote: > > On 2017.07.04 at 06:23 +0200, Markus Trippelsdorf wrote: > >> commit edf064e7c6fec3646b06c944a8e35d1a3de5c2c3 (HEAD, refs/bisect/bad) > >> Author: Goldwyn Rodrigues > >> Date: Tue Jun 20 07:05:49 2017 -0500 > >> > >> btrfs: nowait aio support > >> > >> apparently breaks several shell related features on my system. > > > > Here is a simple testcase: > > > > % echo "foo" >> test > > % echo "foo" >> test > > % cat test > > foo > > % > > > > Thanks for testing. > Yes, pos must be set with iocb->ki_pos for appends. I should not have > removed the initialization. Could you try this patch? It fixes the issue. Thank you. -- Markus
Re: Commit edf064e7c (btrfs: nowait aio support) breaks shells
On 2017.07.04 at 06:23 +0200, Markus Trippelsdorf wrote: > commit edf064e7c6fec3646b06c944a8e35d1a3de5c2c3 (HEAD, refs/bisect/bad) > Author: Goldwyn Rodrigues > Date: Tue Jun 20 07:05:49 2017 -0500 > > btrfs: nowait aio support > > apparently breaks several shell related features on my system. Here is a simple testcase: % echo "foo" >> test % echo "foo" >> test % cat test foo % -- Markus
Commit edf064e7c (btrfs: nowait aio support) breaks shells
commit edf064e7c6fec3646b06c944a8e35d1a3de5c2c3 (HEAD, refs/bisect/bad) Author: Goldwyn Rodrigues Date: Tue Jun 20 07:05:49 2017 -0500 btrfs: nowait aio support apparently breaks several shell related features on my system. In zsh history stopped working, because no new entries are added anymore. I fist noticed the issue when I tried to build mplayer. It uses a shell script to generate a help_mp.h file: % help/help_create.sh help/help_mp-en.h UTF-8 This file gets corrupted: --- help_mp_good.h 2017-07-04 05:38:33.161640826 +0200 +++ help_mp_bad.h 2017-07-04 05:51:00.650730726 +0200 @@ -1,14 +1,8 @@ -/* WARNING! This is a generated file, do NOT edit. - * See the help/ subdirectory for the editable files. */ -#ifndef MPLAYER_HELP_MP_H -#define MPLAYER_HELP_MP_H - -#include -#include "config.h" +#endif /* MPLAYER_HELP_MP_H */ +he English master file */ -// $Revision: 37846 $ -// MASTER FILE. Use this file as base for translations. + for translations. ... (I have attached the testcase.) /dev/sdc3 on / type btrfs (rw,noatime,lazytime,compress=lzo,ssd,noacl,space_cache=v2,subvolid=5,subvol=/) # cat /sys/block/sdc/queue/scheduler [none] mq-deadline -- Markus test.tar.bz2 Description: Binary data
Kyber scheduler brings system to halt when used on swap partition
Using the new Kyber mq scheduler brings my system to a halt as soon as it starts swapping. The swap partition resides on an SSD and is the only partition in use on that drive. Symptoms are stuttering sound and non moving mouse pointer. After a while the monitor switches off, because it gets no signal anymore. At which point only a hard reset will bring the system back. "none" works fine. -- Markus
Re: Playing with BFQ
On 2017.05.03 at 10:00 +0200, Sedat Dilek wrote: > On Tue, May 2, 2017 at 2:16 PM, Markus Trippelsdorf > wrote: > > On 2017.05.02 at 14:07 +0200, Sedat Dilek wrote: > >> On Tue, May 2, 2017 at 10:00 AM, Markus Trippelsdorf > >> wrote: > >> > On 2017.05.02 at 09:54 +0200, Sedat Dilek wrote: > >> >> Hi, > >> >> > >> >> I want to play with BFQ. > >> >> > >> >> My base is block-next as of 28-Apr-2017. > >> [...] > >> >> Not sure if the attached patches make sense (right now). > >> > > >> > No, it doesn't make sense at all. > >> > >> Hmm, I looked at 4.11.0-v8r11 and 0001 has exactly what my 2 patches do > >> :-). > > > > BFQ started as a conventional scheduler. But because mq is the way of > > the future it was ported before it was accepted into mainline. > > > > I am still playing and want to do my own experiences with BFQ. > > Not sure if FIO is a good testcase-tool here. > > So if MQ is the way why isn't the Kconfig called CONFIG_MQ_IOSCHED_BFQ > according to CONFIG_MQ_IOSCHED_DEADLINE? Good point. The current naming is confusing. Also: # cat /sys/block/sda/queue/scheduler mq-deadline [kyber] bfq none These should all be prefixed with mq-. -- Markus
Re: Playing with BFQ
On 2017.05.02 at 14:07 +0200, Sedat Dilek wrote: > On Tue, May 2, 2017 at 10:00 AM, Markus Trippelsdorf > wrote: > > On 2017.05.02 at 09:54 +0200, Sedat Dilek wrote: > >> Hi, > >> > >> I want to play with BFQ. > >> > >> My base is block-next as of 28-Apr-2017. > [...] > >> Not sure if the attached patches make sense (right now). > > > > No, it doesn't make sense at all. > > Hmm, I looked at 4.11.0-v8r11 and 0001 has exactly what my 2 patches do :-). BFQ started as a conventional scheduler. But because mq is the way of the future it was ported before it was accepted into mainline. -- Markus
Re: Playing with BFQ
On 2017.05.02 at 09:54 +0200, Sedat Dilek wrote: > Hi, > > I want to play with BFQ. > > My base is block-next as of 28-Apr-2017. > > First I looked through the Kconfigs. > What is a good setting? > Built as module? > > How can I switch the IO-scheduler - real-time? > > Not sure if the attached patches make sense (right now). No, it doesn't make sense at all. BFQ is a mq scheduler. To use it you should enable SCSI_MQ_DEFAULT. And then you can switch schedulers like: echo "kyber" > /sys/block/sda/queue/scheduler echo "bfq" > /sys/block/sdb/queue/scheduler -- Markus
[PATCH cosmetic] Remove trailing newline in elevator switch error message
Trying to switch to a non-existing elevator currently results in garbled
dmesg output, e.g.:
# echo "foo" > /sys/block/sda/queue/scheduler
elevator: type foo not found
elevator: switch to foo
failed
(note the unintended line break.)
Fix by stripping the trailing newline.
diff --git a/block/elevator.c b/block/elevator.c
index bf11e70f008b..4f13fcd3c626 100644
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -1112,6 +1112,7 @@ static inline bool elv_support_iosched(struct
request_queue *q)
ssize_t elv_iosched_store(struct request_queue *q, const char *name,
size_t count)
{
+ char elevator_name[ELV_NAME_MAX];
int ret;
if (!(q->mq_ops || q->request_fn) || !elv_support_iosched(q))
@@ -1121,7 +1122,9 @@ ssize_t elv_iosched_store(struct request_queue *q, const
char *name,
if (!ret)
return count;
- printk(KERN_ERR "elevator: switch to %s failed\n", name);
+ strlcpy(elevator_name, name, sizeof(elevator_name));
+ strstrip(elevator_name);
+ printk(KERN_ERR "elevator: switch to %s failed\n", elevator_name);
return ret;
}
--
Markus
Re: [PATCH RFC 00/14] Add the BFQ I/O Scheduler to blk-mq
On 2017.03.04 at 17:01 +0100, Paolo Valente wrote: > Hi, > at last, here is my first patch series meant for merging. It adds BFQ > to blk-mq. Don't worry, in this message I won't bore you again with > the wonderful properties of BFQ :) I gave BFQ a quick try. Unfortunately it hangs when I try to delete btrfs snapshots: root 124 0.0 0.0 0 0 ?D07:19 0:03 [btrfs-cleaner] root 125 0.0 0.0 0 0 ?D07:19 0:00 [btrfs-transacti] [ 4372.880116] sysrq: SysRq : Show Blocked State [ 4372.880125] taskPC stack pid father [ 4372.880148] btrfs-cleaner D0 124 2 0x [ 4372.880156] Call Trace: [ 4372.880166] ? __schedule+0x160/0x7c0 [ 4372.880174] ? io_schedule+0x64/0xe0 [ 4372.880179] ? wait_on_page_bit+0x7a/0x100 [ 4372.880183] ? devm_memunmap+0x40/0x40 [ 4372.880189] ? read_extent_buffer_pages+0x25c/0x2c0 [ 4372.880195] ? run_one_async_done+0xc0/0xc0 [ 4372.880200] ? btree_read_extent_buffer_pages+0x60/0x2e0 [ 4372.880206] ? read_tree_block+0x2c/0x60 [ 4372.880211] ? read_block_for_search.isra.38+0xec/0x3a0 [ 4372.880217] ? btrfs_search_slot+0x214/0xbc0 [ 4372.880221] ? lookup_inline_extent_backref+0xfb/0x8c0 [ 4372.880225] ? __btrfs_free_extent.isra.74+0xe9/0xdc0 [ 4372.880231] ? btrfs_merge_delayed_refs+0x57/0x6e0 [ 4372.880235] ? __btrfs_run_delayed_refs+0x60d/0x1340 [ 4372.880239] ? btrfs_run_delayed_refs+0x64/0x280 [ 4372.880243] ? btrfs_should_end_transaction+0x3b/0xa0 [ 4372.880247] ? btrfs_drop_snapshot+0x3b2/0x800 [ 4372.880251] ? __schedule+0x168/0x7c0 [ 4372.880254] ? btrfs_clean_one_deleted_snapshot+0xa4/0xe0 [ 4372.880259] ? cleaner_kthread+0x13a/0x180 [ 4372.880264] ? btree_invalidatepage+0xc0/0xc0 [ 4372.880268] ? kthread+0x144/0x180 [ 4372.880272] ? kthread_flush_work_fn+0x20/0x20 [ 4372.880277] ? ret_from_fork+0x23/0x30 [ 4372.880280] btrfs-transacti D0 125 2 0x [ 4372.880285] Call Trace: [ 4372.880290] ? __schedule+0x160/0x7c0 [ 4372.880295] ? io_schedule+0x64/0xe0 [ 4372.880300] ? wait_on_page_bit_common.constprop.57+0x160/0x180 [ 4372.880303] ? devm_memunmap+0x40/0x40 [ 4372.880307] ? __filemap_fdatawait_range+0xd3/0x140 [ 4372.880311] ? clear_state_bit.constprop.82+0xf7/0x180 [ 4372.880315] ? __clear_extent_bit.constprop.79+0x138/0x3c0 [ 4372.880319] ? filemap_fdatawait_range+0x9/0x60 [ 4372.880323] ? __btrfs_wait_marked_extents.isra.18+0xc1/0x100 [ 4372.880327] ? btrfs_write_and_wait_marked_extents.constprop.23+0x49/0x80 [ 4372.880331] ? btrfs_commit_transaction+0x8e1/0xb00 [ 4372.880334] ? join_transaction.constprop.24+0x10/0xa0 [ 4372.880340] ? wake_bit_function+0x60/0x60 [ 4372.880345] ? transaction_kthread+0x185/0x1a0 [ 4372.880350] ? btrfs_cleanup_transaction+0x500/0x500 [ 4372.880354] ? kthread+0x144/0x180 [ 4372.880358] ? kthread_flush_work_fn+0x20/0x20 [ 4372.880362] ? ret_from_fork+0x23/0x30 [ 4372.880367] ntpdD0 175 1 0x0004 [ 4372.880372] Call Trace: [ 4372.880375] ? __schedule+0x160/0x7c0 [ 4372.880379] ? schedule_preempt_disabled+0x2d/0x80 [ 4372.880383] ? __mutex_lock.isra.5+0x17b/0x4c0 [ 4372.880386] ? wait_current_trans+0x15/0xc0 [ 4372.880391] ? btrfs_free_path+0xe/0x20 [ 4372.880395] ? btrfs_pin_log_trans+0x14/0x40 [ 4372.880400] ? btrfs_rename2+0x28e/0x19c0 [ 4372.880404] ? path_init+0x187/0x3e0 [ 4372.880407] ? unlazy_walk+0x4b/0x100 [ 4372.880410] ? terminate_walk+0x8d/0x100 [ 4372.880414] ? filename_parentat+0x1e9/0x2c0 [ 4372.880420] ? __kmalloc_track_caller+0xc4/0x100 [ 4372.880424] ? vfs_rename+0x33f/0x7e0 [ 4372.880428] ? SYSC_renameat2+0x53c/0x680 [ 4372.880433] ? entry_SYSCALL_64_fastpath+0x13/0x94 [ 4372.880437] fcron D0 178 1 0x [ 4372.880441] Call Trace: [ 4372.880445] ? __schedule+0x160/0x7c0 [ 4372.880448] ? schedule_preempt_disabled+0x2d/0x80 [ 4372.880452] ? __mutex_lock.isra.5+0x17b/0x4c0 [ 4372.880458] ? pagevec_lookup_tag+0x18/0x20 [ 4372.880462] ? btrfs_log_dentry_safe+0x4cd/0xac0 [ 4372.880466] ? btrfs_start_transaction+0x249/0x460 [ 4372.880470] ? btrfs_sync_file+0x288/0x3c0 [ 4372.880475] ? btrfs_file_write_iter+0x3a9/0x4e0 [ 4372.880479] ? vfs_write+0x26c/0x2c0 [ 4372.880483] ? SyS_write+0x3d/0xa0 [ 4372.880486] ? SyS_fchown+0x7b/0xa0 [ 4372.880491] ? entry_SYSCALL_64_fastpath+0x13/0x94 [ 4372.880508] kworker/u8:8D0 759 2 0x [ 4372.880518] Workqueue: btrfs-submit btrfs_submit_helper [ 4372.880520] Call Trace: [ 4372.880524] ? __schedule+0x160/0x7c0 [ 4372.880529] ? io_schedule+0x64/0xe0 [ 4372.880534] ? blk_mq_get_tag+0x212/0x320 [ 4372.880538] ? wake_bit_function+0x60/0x60 [ 4372.880544] ? __blk_mq_alloc_request+0x11/0x1c0 [ 4372.880548] ? blk_mq_sched_get_request+0x17e/0x220 [ 4372.880553] ? blk_sq_make_request+0xd3/0x4c0 [ 4372.880557] ? blk_mq_sched_dispatch_requests+0x104/0x160 [ 4372.880561] ? generic_make_request+0xc3/0x2e0 [ 4372.880564] ? submit_bio+0x58/0x100 [
Re: [GIT PULL] Block pull request for- 4.11-rc1
On 2017.02.22 at 11:44 -0700, Jens Axboe wrote: > On 02/22/2017 11:42 AM, Linus Torvalds wrote: > > On Wed, Feb 22, 2017 at 10:26 AM, Linus Torvalds > > wrote: > >> > >> And dammit, IF YOU DON'T EVEN KNOW, WHY THE HELL ARE YOU ASKING THE POOR > >> USER? > > > > Basically, I'm pushing back on config options that I can't personally > > even sanely answer. > > I got that much, and I don't disagree on that part. > > > If it's a config option about "do I have a particular piece of > > hardware", it makes sense. But these new ones were just complete > > garbage. > > > > The whole "default IO scheduler" thing is a disease. We should stop > > making up these shit schedulers and then say "we don't know which one > > works best for you". > > > > All it does is encourage developers to make shortcuts and create crap > > that isn't generically useful, and then blame the user and say "well, > > you should have picked a different scheduler" when they say "this does > > not work well for me". > > > > We have had too many of those kinds of broken choices. And when the > > new Kconfig options get so confusing and so esoteric that I go "Hmm, I > > have no idea if my hardware does a single queue or not", I put my foot > > down. > > > > When the IO scheduler questions were about a generic IO scheduler for > > everything, I can kind of understand them. I think it was still a > > mistake (for the reasons outline above), but at least it was a > > comprehensible question to ask. > > > > But when it gets to "what should I do about a single-queue version of > > a MQ scheduler", the question is no longer even remotely sensible. The > > question should simply NOT EXIST. There is no possible valid reason to > > ask that kind of crap. > > OK, so here's what I'll do: > > 1) We'll kill the default scheduler choices. sq blk-mq will default to >mq-deadline, mq blk-mq will default to "none" (at least for now, until >the new scheduler is done). But what about e.g. SATA SSDs? Wouldn't they be better off without any scheduler? So perhaps setting "none" for queue/rotational==0 and mq-deadline for spinning drives automatically in the sq blk-mq case? -- Markus
