Jens Axboe writes:
> On 10/9/19 2:34 AM, Stefan Hajnoczi wrote:
>> Hi Jens,
>> I would like to add a liburing package to Fedora. The liburing 0.1
>> release was in January and there have been many changes since then. Is
>> now a good time for a 0.2 release?
>
> I've been thinking the same. I'll
Jackie Liu writes:
> If cq_entries is smaller than sq_entries, it will cause a lot of overflow
> to appear. when customizing cq_entries, at least let him be no smaller than
> sq_entries.
>
> Fixes: 95d8765bd9f2 ("io_uring: allow application controlled CQ ring size")
> Signed-off-by: Jackie Liu
>
Christoph Hellwig writes:
> Given that pmem simply loops over an arbitrarily large bio I think
> we also need a threshold for which to allow nowait I/O. While it
> won't block for giant I/Os, doing all of them in the submitter
> context isn't exactly the idea behind the nowait I/O.
>
> I'm not r
Chaitanya Kulkarni writes:
> On 8/2/23 08:27, Jeff Moyer wrote:
>> So, I think with the change to return -EAGAIN for writes to poisoned
>> memory, this patch is probably ok.
>
> I believe you mean the same one I've provided earlier incremental ..
Yes, sorry if that w
Eric Wheeler writes:
> [+cc Mikulas Patocka, Jeff Moyer; Do either of you have any input on Lars'
> commentary related to patchwork #'s 9204125 and 7398411 and BZ#119841? ]
Sorry, I don't have any time to look at this right now.
Cheers,
Jeff
>
> On Tue, 19 Jul
Hi, Adam,
Adam Manzanares writes:
> Patch adds an association between iocontext ioprio and the ioprio of
> a request. This feature is only enabled if a queue flag is set to
> indicate that requests should have ioprio associated with them. The
> queue flag is exposed as the req_prio queue sysfs e
Damien Le Moal writes:
> diff --git a/Documentation/ABI/testing/sysfs-block
> b/Documentation/ABI/testing/sysfs-block
> index 75a5055..ee2d5cd 100644
> --- a/Documentation/ABI/testing/sysfs-block
> +++ b/Documentation/ABI/testing/sysfs-block
> @@ -251,3 +251,16 @@ Description:
> si
Damien Le Moal writes:
> + if (!is_power_of_2(zone_blocks)) {
> + if (sdkp->first_scan)
> + sd_printk(KERN_NOTICE, sdkp,
> + "Devices with non power of 2 zone "
> + "size are not supported\n");
> +
Shaun Tancheff writes:
> On Tue, Oct 18, 2016 at 11:58 AM, Jeff Moyer wrote:
>> Damien Le Moal writes:
>>
>>> + if (!is_power_of_2(zone_blocks)) {
>>> + if (sdkp->first_scan)
>>> + sd_printk(KERN_NOTICE, sdkp,
"Martin K. Petersen" writes:
>>>>>> "Jeff" == Jeff Moyer writes:
>
> Jeff,
>
> Jeff> Are power of 2 zone sizes required by the standard? I see why
> Jeff> you've done this, but I wonder if we're artificially limiting the
&
Right now, any of the above three drivers will report Q events in
blktrace but no corresponding C events. Fix it.
Signed-off-by: Jeff Moyer
diff --git a/drivers/nvdimm/blk.c b/drivers/nvdimm/blk.c
index 9faaa96..90676f3 100644
--- a/drivers/nvdimm/blk.c
+++ b/drivers/nvdimm/blk.c
@@ -19,6
Christoph Hellwig writes:
> On Wed, Nov 09, 2016 at 02:08:33PM -0500, Jeff Moyer wrote:
>> Right now, any of the above three drivers will report Q events in
>> blktrace but no corresponding C events. Fix it.
>
> It seems like that trace point should simply go into bio_e
Christoph Hellwig writes:
> On Wed, Nov 09, 2016 at 02:31:30PM -0500, Jeff Moyer wrote:
>> bio_endio is still called for request_fn drivers, so you'd see two
>> completion events for those drivers if we did that, no?
>
> We'd see the bio_endio trace in addition to
Christoph Hellwig writes:
> On Wed, Nov 09, 2016 at 02:43:58PM -0500, Jeff Moyer wrote:
>> But on the issue side, we have different trace actions: Q vs. I. On the
>> completion side, we just have C. You'd end up getting two C events for
>> each Q, and that may confus
Ross Zwisler writes:
> FWIW I think BRD has this same issue where we get block_bio_queue tracepoint
> events but not block_bio_complete. Solving this in bio_endio() would fix that
> driver as well.
Yeah, there are several other drivers that will benefit.
> Where does the Q (bio enqueue), I (re
/sys/block//queue/io_poll is a boolean. Fix the docs.
Signed-off-by: Jeff Moyer
diff --git a/Documentation/block/queue-sysfs.txt
b/Documentation/block/queue-sysfs.txt
index 5164215..c0a3bb5 100644
--- a/Documentation/block/queue-sysfs.txt
+++ b/Documentation/block/queue-sysfs.txt
@@ -54,9
Jens Axboe writes:
> On 01/03/2017 03:51 PM, Jeff Moyer wrote:
>>
>> /sys/block//queue/io_poll is a boolean. Fix the docs.
>>
>> Signed-off-by: Jeff Moyer
>>
>> diff --git a/Documentation/block/queue-sysfs.txt
>> b/Documentation/block/que
Hannes Reinecke writes:
> At LSF I'd like to discuss
> - Do we consider blktrace (and any other tracepoint in eg SCSI) as a
> stable API?
I don't have a strong opinion on this.
> - How do we go about modifying blktrace?
Blktrace has a version number associated with trace events. Bump the
vers
Chandan Rajendra writes:
> The code currently uses sdio->blkbits to compute the number of blocks to
> be cleaned. However sdio->blkbits is derived from the logical block size
> of the underlying block device (Refer to the definition of
> do_blockdev_direct_IO()). Due to this, generic/299 test wou
to vblk->disk->queue on success.
>
> Signed-off-by: Omar Sandoval
Reviewed-by: Jeff Moyer
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Additionally, don't assign directly to disk->queue, otherwise
blk_put_queue (called via put_disk) will choke (panic) on the errno
stored there.
Bug found by code inspection after Omar found a similar issue in
virtio_blk. Compile-tested only.
Signed-off-by: Jeff Moyer
diff --git a
:
don't read inode->i_blkbits multiple times") for the reasoning, and
commit b87570f5d3496 ("Fix a crash when block device is read and block
size is changed at the same time") for a more detailed problem
description and reproducer.
Fixes: 20ce44d545844
Signed-off-by: Jeff Moye
Christoph Hellwig writes:
> On Thu, Jan 12, 2017 at 05:13:52PM +0900, Damien Le Moal wrote:
>> (3) Any other idea ?
>
> Do nothing and ignore the problem. This whole idea so braindead that
> the person coming up with the T10 language should be shot. Either a device
> has 511 logical sectors or
Hi, Kashyap,
I'm CC-ing Kent, seeing how this is his code.
Kashyap Desai writes:
> Objective of this patch is -
>
> To move code used in bcache module in block layer which is used to
> find IO stream. Reference code @drivers/md/bcache/request.c
> check_should_bypass(). This is a high level p
Kirill Tkhai writes:
> Hi, Benjamin,
>
> On 04.12.2017 19:52, Benjamin LaHaise wrote:
>> Hi Kirill,
>>
>> On Mon, Dec 04, 2017 at 07:12:51PM +0300, Kirill Tkhai wrote:
>>> Hi,
>>>
>>> this patch set introduces accounting aio_nr and aio_max_nr per blkio cgroup.
>>> It may be used to limit number
Kirill Tkhai writes:
> On 05.12.2017 00:52, Tejun Heo wrote:
>> Hello, Kirill.
>>
>> On Tue, Dec 05, 2017 at 12:44:00AM +0300, Kirill Tkhai wrote:
Can you please explain how this is a fundamental resource which can't
be controlled otherwise?
>>>
>>> Currently, aio_nr and aio_max_nr are
Kirill Tkhai writes:
>> I think you just need to account the completion ring.
>
> A request of struct aio_kiocb type consumes much more memory, than
> struct io_event does. Shouldn't we account it too?
Not in my opinion. The completion ring is the part that gets pinned for
long periods of time.
"Darrick J. Wong" writes:
>> - Whenever you mount a filesystem with DAX, it spits out a message that says
>> "DAX enabled. Warning: EXPERIMENTAL, use at your own risk". What criteria
>> needs to be met for DAX to no longer be considered experimental?
>
> For XFS I'd like to get reflink worki
Christoph Hellwig writes:
> On Mon, Jan 16, 2017 at 05:50:33PM -0800, Darrick J. Wong wrote:
>> I wouldn't consider it a barrier in general (since ext4 also prints
>> EXPERIMENTAL warnings for DAX), merely one for XFS. I don't even think
>> it's that big of a hurdle -- afaict XFS ought to be abl
Christoph Hellwig writes:
> On Tue, Jan 17, 2017 at 09:54:27AM -0500, Jeff Moyer wrote:
>> I spoke with Dave before the holidays, and he indicated that
>> PMEM_IMMUTABLE would be an acceptable solution to allowing applications
>> to flush data completely from userspace. I
exactly one caller of trace_block_bio_complete
and one caller of trace_block_rq_complete. More importantly, all
bio-based drivers now generate C events, which is useful for
performance analysis.
Suggested-by: Christoph Hellwig
Signed-off-by: Jeff Moyer
---
Testing: I made sure that request-based
Jens Axboe writes:
> On 01/17/2017 01:57 PM, Jeff Moyer wrote:
>> Only a few bio-based drivers actually generate blktrace completion
>> (C) events. Instead of changing all bio-based drivers to call
>> trace_block_bio_complete, move the tracing to bio_complete, and remove
&g
Hi, Jens,
Jens Axboe writes:
> I like the change, hate the naming. I'd prefer one of two things:
>
> - Add bio_endio_complete() instead. That name sucks too, the
> important part is flipping the __name() to have a trace
> version instead.
ITYM a notrace version. By default, we want tracing
Slava Dubeyko writes:
>> Well, the situation with NVM is more like with DRAM AFAIU. It is quite
>> reliable
>> but given the size the probability *some* cell has degraded is quite high.
>> And similar to DRAM you'll get MCE (Machine Check Exception) when you try
>> to read such cell. As Vishal w
Jan Kara writes:
> On Tue 17-01-17 15:14:21, Vishal Verma wrote:
>> Your note on the online repair does raise another tangentially related
>> topic. Currently, if there are badblocks, writes via the bio submission
>> path will clear the error (if the hardware is able to remap the bad
>> locations
Hi, Slava,
Slava Dubeyko writes:
>>The data is lost, that's why you're getting an ECC. It's tantamount
>>to -EIO for a disk block access.
>
> I see the three possible cases here:
> (1) bad block has been discovered (no remap, no recovering) -> data is
>> lost; -EIO for a disk block access, bloc
Hou Tao writes:
> Hi all,
>
> We need to throttle the O_DIRECT IO on data and metadata device
> of a dm-thin pool and encounter some problems. If we set the
> limitation on the root blkcg, the throttle works. If we set the
> limitation on a child blkcg, the throttle doesn't work well.
>
> The rea
Hi, Christoph,
Christoph Hellwig writes:
> Remove the request_idx parameter, which can't be used safely now that we
> support I/O schedulers with blk-mq. Except for a superflous check in
> mtip32xx it was unused anyway.
I'm not sure how your patch builds. If I look at the mtip32xx driver in
f
Christoph Hellwig writes:
>> If you got rid of request_idx, then this shouldn't build. So, is there
>> some other prerequisite patch I'm missing?
>
> Yes, both you and I are. It's "mtip32xx: use runtime tag to initialize
> command header" which is in Jens' for-4.12/block tree, but not in the
>
Jens Axboe writes:
> Add hint on whether a read was served out of the page cache, or if it
> hit media. This is useful for buffered async IO, O_DIRECT reads would
> never have this set (for obvious reasons).
>
> If the read hit page cache, cqe->flags will have IOCQE_FLAG_CACHEHIT
> set.
We may w
Hi, Jens,
It looks to me like calling io_uring_register more than once (for either
IORING_REGISTER_BUFFERS or IORING_REGISTER_FILES) will leak the
references taken in previous calls.
Signed-off-by: Jeff Moyer
---
If this makes sense to you, feel free to just fold this into your
patches w/o
Jens Axboe writes:
> On 1/16/19 5:50 PM, Jeff Moyer wrote:
>> Hi, Jens,
>>
>> It looks to me like calling io_uring_register more than once (for either
>> IORING_REGISTER_BUFFERS or IORING_REGISTER_FILES) will leak the
>> references taken in previous calls.
>
Jens Axboe writes:
> On 1/17/19 5:48 AM, Roman Penyaev wrote:
>> On 2019-01-16 18:49, Jens Axboe wrote:
>>
>> [...]
>>
>>> +static int io_allocate_scq_urings(struct io_ring_ctx *ctx,
>>> + struct io_uring_params *p)
>>> +{
>>> + struct io_sq_ring *sq_ring;
>>> +
Jens Axboe writes:
> On 1/17/19 1:09 PM, Jens Axboe wrote:
>> On 1/17/19 1:03 PM, Jeff Moyer wrote:
>>> Jens Axboe writes:
>>>
>>>> On 1/17/19 5:48 AM, Roman Penyaev wrote:
>>>>> On 2019-01-16 18:49, Jens Axboe wrote:
>>>>&g
Jens Axboe writes:
>>> It seems that sq_entries, cq_entries are not limited at all. Can nasty
>>> app consume a lot of kernel pages calling io_setup_uring() from a loop
>>> passing random entries number? (or even better: decreasing entries
>>> number,
>>> in order to consume
Jens Axboe writes:
>> So all we need to do is modify gpg2 so that is requires more locked
>> memory, and we're golden! ;-)
>
> Haha, that's some nice digging there!
>
> Yes, we could bump it, but with the default, we can get a 512 sized
> ring per user, that's 13 pages (rounded up). Probably goo
FLAG_NAME(NOUNMAP),
> CMD_FLAG_NAME(NOWAIT),
> + CMD_FLAG_NAME(NOUNMAP),
> + CMD_FLAG_NAME(HIPRI),
> };
> #undef CMD_FLAG_NAME
Acked-by: Jeff Moyer
You might consider also adding a comment above the req_flag_bits enum
noting that modifications also need to be propagated to cmd_flag_name.
Jens Axboe writes:
> @@ -1270,6 +1445,27 @@ static int io_sq_offload_start(struct io_ring_ctx *ctx)
> if (!ctx->sqo_files)
> goto err;
>
> + if (ctx->flags & IORING_SETUP_SQPOLL) {
> + if (p->flags & IORING_SETUP_SQ_AFF) {
> + ctx->sqo_thr
Jens Axboe writes:
> +static int __io_uring_enter(struct io_ring_ctx *ctx, unsigned to_submit,
> + unsigned min_complete, unsigned flags,
> + const sigset_t __user *sig, size_t sigsz)
> +{
> + int submitted, ret;
> +
> + submitted = ret = 0;
Jens Axboe writes:
> On 1/29/19 11:31 AM, Jens Axboe wrote:
>>> The code looks a little clumsy to me. Why not:
>>>
>>> while (!list_empty(&ctx->poll_list)) {
>>> int ret = io_do_iopoll(ctx, nr_events, min);
>>> if (ret)
>>> return ret;
>>>
>>>
Hi, Jens,
Jens Axboe writes:
> +static void io_ring_ctx_free(struct io_ring_ctx *ctx)
> +{
> + destroy_workqueue(ctx->sqo_wq);
You need to make sure sqo_wq is non-null before calling
destroy_workqueue.
-Jeff
Jeff Moyer writes:
> Hi, Jens,
>
> Jens Axboe writes:
>
>> +static void io_ring_ctx_free(struct io_ring_ctx *ctx)
>> +{
>> +destroy_workqueue(ctx->sqo_wq);
>
> You need to make sure sqo_wq is non-null before calling
> destroy_workqueue.
You als
Hi, Jens,
Jens Axboe writes:
> +static int io_sqe_buffer_unregister(struct io_ring_ctx *ctx)
> +{
> + int i, j;
> +
> + if (!ctx->user_bufs)
> + return -ENXIO;
> +
> + for (i = 0; i < ctx->sq_entries; i++) {
> + struct io_mapped_ubuf *imu = &ctx->user_bufs[i];
Hi, Jens,
> +static int io_poll_add(struct io_kiocb *req, const struct io_uring_sqe *sqe)
> +{
[...]
> + /* one for removal from waitqueue, one for this function */
> + refcount_set(&req->refs, 2);
> +
> + mask = vfs_poll(poll->file, &ipt.pt) & poll->events;
> + if (unlikely(!pol
Hi, Jens,
Jens Axboe writes:
> For now, buffers must not be file backed. If file backed buffers are
> passed in, the registration will fail with -1/EOPNOTSUPP. This
> restriction may be relaxed in the future.
[...]
> + down_write(¤t->mm->mmap_sem);
> + pret = get_user_p
Shenghui Wang writes:
> This issue is found by running liburing/test/io_uring_setup test.
>
> When test run, the testcase "attempt to bind to invalid cpu" would not
> pass with messages like:
>io_uring_setup(1, 0xbfc2f7c8), \
> flags: IORING_SETUP_SQPOLL|IORING_SETUP_SQ_AFF, \
> resv: 0x0
Christoph Hellwig writes:
> On Tue, Apr 30, 2019 at 09:28:15PM -0700, Chaitanya Kulkarni wrote:
>> @@ -104,7 +120,12 @@ struct blk_io_trace {
>> __u64 time; /* in nanoseconds */
>> __u64 sector; /* disk offset */
>> __u32 bytes;/* transfer length *
Jens Axboe writes:
> On 5/1/19 5:56 AM, Jeff Moyer wrote:
>> Shenghui Wang writes:
>>
>>> This issue is found by running liburing/test/io_uring_setup test.
>>>
>>> When test run, the testcase "attempt to bind to invalid cpu" would not
Jens Axboe writes:
> Agree, I've cleaned it up, it was a bit of a mess.
LGTM, thanks!
-Jeff
ine(cpu))
> goto err;
>
> ctx->sqo_thread = kthread_create_on_cpu(io_sq_thread,
Reviewed-by: Jeff Moyer
Hi, Alexey,
Alexey Dobriyan writes:
> 5.0 deleted three io schedulers and more importantly CONFIG_DEFAULT_IOSCHED
> option:
>
> commit f382fb0bcef4c37dc049e9f6963e3baf204d815c
> block: remove legacy IO schedulers
>
> After figuring out that I silently became "noop" customer enabling
Hi, Adam,
adam.manzana...@wdc.com writes:
> From: Adam Manzanares
>
> This is the per-I/O equivalent of the ioprio_set system call.
>
> When IOCB_FLAG_IOPRIO is set on the iocb aio_flags field, then we set the
> newly added kiocb ki_ioprio field to the value in the iocb aio_reqprio field.
>
> Wh
Hi, Adam,
adam.manzana...@wdc.com writes:
> From: Adam Manzanares
>
> This is the per-I/O equivalent of the ioprio_set system call.
> See the following link for performance implications on a SATA HDD:
> https://lkml.org/lkml/2016/12/6/495
>
> First patch factors ioprio_check_cap function out of
ld.
>
> We set the blkdev bio iopriority unconditionally, so we need to guarantee the
> kiocb is initialized properly. Added changes to the loopback driver and
> init_sync_kiocb to achieve this.
>
> This patch depends on block: add ioprio_check_cap function.
>
> Signed-o
adam.manzana...@wdc.com writes:
> From: Adam Manzanares
>
> Now that kiocb has an ioprio field copy this over to the bio when it is
> created from the kiocb.
>
> Signed-off-by: Adam Manzanares
Reviewed-by: Jeff Moyer
> ---
> fs/block_dev.c | 1 +
> 1 file chang
adam.manzana...@wdc.com writes:
> From: Adam Manzanares
>
> Now that kiocb has an ioprio field copy this over to the bio when it is
> created from the kiocb during direct IO.
>
> Signed-off-by: Adam Manzanares
Reviewed-by: Jeff Moyer
> ---
> fs/iomap.c | 1 +
>
has sufficient
> priviledges to submit IOPRIO_RT commands. This patch creates the
> ioprio_check_cap function to be used by the ioprio_set system call and also by
> the aio interface.
>
> Signed-off-by: Adam Manzanares
> Reviewed-by: Christoph Hellwig
Reviewed-by: Jeff Moyer
>
adam.manzana...@wdc.com writes:
> From: Adam Manzanares
>
> Now that kiocb has an ioprio field copy this over to the bio when it is
> created from the kiocb.
>
> Signed-off-by: Adam Manzanares
> ---
> fs/block_dev.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/block_dev.c b/fs/bl
adam.manzana...@wdc.com writes:
> From: Adam Manzanares
>
> Now that kiocb has an ioprio field copy this over to the bio when it is
> created from the kiocb.
>
> Signed-off-by: Adam Manzanares
Reviewed-by: Jeff Moyer
Thanks!
Jeff
> ---
> fs/block_dev.c | 2
Bryan Gurney reported I/O errors when using dm-zoned with a host-managed
SMR device. It turns out he was using CFQ, which is the default.
Unfortunately, as of v4.16, only the deadline schedulers work well with
host-managed SMR devices. This series aatempts to switch the elevator
to deadline for t
The next patch will add a caller that can't trigger module loads.
Also export this function for that caller.
Signed-off-by: Jeff Moyer
---
block/blk.h | 2 ++
block/elevator.c | 7 ---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/block/blk.h b/block/blk.h
only submitting 1 I/O per zone). Change our
defaults to provide a working configuration.
Reported-by: Bryan Gurney
Signed-off-by: Jeff Moyer
---
block/blk-sysfs.c | 24
1 file changed, 24 insertions(+)
diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
index d00d1b0..ec
Hi, Jens,
Jens Axboe writes:
> On 5/25/18 3:14 PM, Jeff Moyer wrote:
>> Bryan Gurney reported I/O errors when using dm-zoned with a host-managed
>> SMR device. It turns out he was using CFQ, which is the default.
>> Unfortunately, as of v4.16, only the deadline sche
Hi, Jens,
Jens Axboe writes:
> On 5/30/18 2:49 AM, Christoph Hellwig wrote:
>> While I really don't want drivers to change the I/O schedule themselves
>> we have a class of devices (zoned) that don't work at all with certain
>> I/O schedulers. The kernel not chosing something sane and requiring
Jens Axboe writes:
> On 5/30/18 9:06 AM, Jeff Moyer wrote:
>> Hi, Jens,
>>
>> Jens Axboe writes:
>>
>>> On 5/30/18 2:49 AM, Christoph Hellwig wrote:
>>>> While I really don't want drivers to change the I/O schedule themselves
>>>&g
to complete the next request(s).
>
> Signed-off-by: Jens Axboe
Reviewed-by: Jeff Moyer
Minor nit below.
> @@ -1994,7 +2014,7 @@ static void io_sq_wq_submit_work(struct work_struct
> *work)
> */
> static bool io_add_to_prev_work(struct async_list *list, struct io_
t; Signed-off-by: Jens Axboe
Reviewed-by: Jeff Moyer
>
> --
>
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index 4bc3ee4ea81f..3c8859d417eb 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -3356,15 +3356,12 @@ SYSCALL_DEFINE6(io_uring_enter, unsigned int, fd,
&g
Jens Axboe writes:
> Allows the application to remove/replace/add files to/from a file set.
> Passes in a struct:
>
> struct io_uring_files_update {
> __u32 offset;
> __s32 *fds;
> };
>
> that holds an array of fds, size of array passed in through the usual
> nr_args part of the i
Jens Axboe writes:
> On 10/4/19 9:34 AM, Jeff Moyer wrote:
>> If I'm reading this (and the code) right, that means you can't add files
>> to a set. Wouldn't that be a useful thing to do, instead of just
>> replacing existing ones?
>
> You can add files
Jens Axboe writes:
> On 10/4/19 10:03 AM, Jeff Moyer wrote:
>> Jens Axboe writes:
>>
>>> On 10/4/19 9:34 AM, Jeff Moyer wrote:
>>>> If I'm reading this (and the code) right, that means you can't add files
>>>> to a set. Wouldn'
rogram--diff below. The test passes, of course. :)
Reviewed-by: Jeff Moyer
Cheers,
Jeff
diff --git a/test/file-register.c b/test/file-register.c
index b25f0f5..322545f 100644
--- a/test/file-register.c
+++ b/test/file-register.c
@@ -358,6 +358,40 @@ err:
return 1;
}
+/*
+ * Regist
Hi, Jens,
Jens Axboe writes:
> If we have fixed user buffers, we can map them into the kernel when we
> setup the io_context. That avoids the need to do get_user_pages() for
> each and every IO.
>
> To utilize this feature, the application must set both
> IOCTX_FLAG_USERIOCB, to provide iocb's i
Jens Axboe writes:
>>> A limit of 4M is imposed as the largest buffer we currently support.
>>> There's nothing preventing us from going larger, but we need some cap,
>>> and 4M seemed like it would definitely be big enough.
>>
>> Doesn't this mean that a user can pin a bunch of memory? Somethi
Jens Axboe writes:
> From: Christoph Hellwig
>
> Just call blk_poll on the iocb cookie, we can derive the block device
> from the inode trivially.
Does this work for multi-device file systems?
-Jeff
>
> Reviewed-by: Johannes Thumshirn
> Signed-off-by: Christoph Hellwig
> Signed-off-by: Jens
Jens Axboe writes:
> From: Christoph Hellwig
>
> This new methods is used to explicitly poll for I/O completion for an
> iocb. It must be called for any iocb submitted asynchronously (that
> is with a non-null ki_complete) which has the IOCB_HIPRI flag set.
>
> The method is assisted by a new k
Jens Axboe writes:
> It's 192 bytes, fairly substantial. Most items don't need to be cleared,
> especially not upfront. Clear the ones we do need to clear, and leave
> the other ones for setup when the iocb is prepared and submitted.
What performance gains do you see from this?
-Jeff
> Reviewe
Jens Axboe writes:
> Plugging is meant to optimize submission of a string of IOs, if we don't
> have more than 2 being submitted, don't bother setting up a plug.
Is there really that much overhead in blk_{start|finish}_plug?
-Jeff
>
> Reviewed-by: Christoph Hellwig
> Signed-off-by: Jens Axboe
Jens Axboe writes:
> On 12/6/18 12:27 PM, Jeff Moyer wrote:
>> Jens Axboe writes:
>>
>>> It's 192 bytes, fairly substantial. Most items don't need to be cleared,
>>> especially not upfront. Clear the ones we do need to clear, and leave
>>> th
Hi, Jens,
Jens Axboe writes:
> You can also find the patches in my aio-poll branch:
>
> http://git.kernel.dk/cgit/linux-block/log/?h=aio-poll
>
> or by cloning:
>
> git://git.kernel.dk/linux-block aio-poll
I made an xfs file system on a partition of an nvme device. I created a
1 GB file on tha
Jens Axboe writes:
> BTW, quick guess is that it doesn't work so well with fixed buffers, as that
> hasn't been tested. You could try and remove IOCTX_FLAG_FIXEDBUFS from the
> test program and see if that works.
That results in a NULL pointer dereference. I'll stick to block device
testing for
Jens Axboe writes:
> The submission queue (SQ) and completion queue (CQ) rings are shared
> between the application and the kernel. This eliminates the need to
> copy data back and forth to submit and complete IO. We use the same
> structures as the old aio interface. The SQ rings are indexes int
Hi, Logan,
Logan Gunthorpe writes:
> Hey,
>
> I found a regression in v5.0-rc1 this morning. My system panics on boot.
> I've attached a log of the panic.
>
> I bisected to find the problematic commit is:
>
> Fixes: 9d037ad707ed ("block: remove req->timeout_list")
>
> But it makes no sense to me
> Cc: Intel SCU Linux support
> Cc: Artur Paszkiewicz
> Cc: "James E.J. Bottomley"
> Cc: "Martin K. Petersen"
> Cc: Christoph Hellwig
> Cc: Jens Axboe
> Cc: Jeff Moyer
Nice job, and excellent commit message. We'll need a similar patch for
lpfc.
Rev
There was some confusion about what these functions did. Make it clear
that this is a hint for upper layers to pass to the block layer, and
that it does not guarantee that I/O will not be submitted between a
start and finish plug.
Reported-by: "Darrick J. Wong"
Signed-off-by: Jeff Mo
94 matches
Mail list logo
