Re: [LSF/MM TOPIC] Un-addressable device memory and block/fs implications

On Tue, Dec 13, 2016 at 08:07:58PM -0500, Jerome Glisse wrote: > On Wed, Dec 14, 2016 at 11:14:22AM +1100, Dave Chinner wrote: > > On Tue, Dec 13, 2016 at 05:55:24PM -0500, Jerome Glisse wrote: > > > On Wed, Dec 14, 2016 at 09:13:22AM +1100, Dave Chinner wrote: > > > > On Tue, Dec 13, 2016 at

Re: [LSF/MM TOPIC] Un-addressable device memory and block/fs implications

On Wed, Dec 14, 2016 at 5:15 AM, Jerome Glisse wrote: > I would like to discuss un-addressable device memory in the context of > filesystem and block device. Specificaly how to handle write-back, read, > ... when a filesystem page is migrated to device memory that CPU can not

Re: [PATCH] block_dev: don't update file access position for sync direct IO

On 12/13/2016 08:07 PM, Shaohua Li wrote: > For sync direct IO, generic_file_direct_write/generic_file_read_iter > will update file access position. Don't duplicate the update in > .direct_IO. This cause my raid array can't assemble. That's not great... Thanks, added. -- Jens Axboe -- To

[PATCH] block_dev: don't update file access position for sync direct IO

For sync direct IO, generic_file_direct_write/generic_file_read_iter will update file access position. Don't duplicate the update in .direct_IO. This cause my raid array can't assemble. Cc: Christoph Hellwig Cc: Jens Axboe Signed-off-by: Shaohua Li ---

Re: extend bi_size to unsigned long ?

Hi Coly, On Tue, Dec 13, 2016 at 10:53 PM, Coly Li wrote: > Hi linux-block and linux-nvme lists, > > Recently when I work on md-raid0 DISCARD optimization, I found the > maximum DISCARD bio length that raid0_make_request() receives is 8388608 > sectors. I find it is because of the

Re: [LSF/MM TOPIC] Un-addressable device memory and block/fs implications

On Wed, Dec 14, 2016 at 11:14:22AM +1100, Dave Chinner wrote: > On Tue, Dec 13, 2016 at 05:55:24PM -0500, Jerome Glisse wrote: > > On Wed, Dec 14, 2016 at 09:13:22AM +1100, Dave Chinner wrote: > > > On Tue, Dec 13, 2016 at 04:24:33PM -0500, Jerome Glisse wrote: > > > > On Wed, Dec 14, 2016 at

Re: [LSF/MM TOPIC] Un-addressable device memory and block/fs implications

On Tue, Dec 13, 2016 at 05:55:24PM -0500, Jerome Glisse wrote: > On Wed, Dec 14, 2016 at 09:13:22AM +1100, Dave Chinner wrote: > > On Tue, Dec 13, 2016 at 04:24:33PM -0500, Jerome Glisse wrote: > > > On Wed, Dec 14, 2016 at 08:10:41AM +1100, Dave Chinner wrote: > > > > > From kernel point of view

Re: [GIT PULL] Block core changes for 4.10

Hi Linus, On Sun, 11 Dec 2016 18:52:29 -0700 Jens Axboe wrote: > > Note that this pull will throw 3 trivial merge conflicts, since we had > patches that went into mainline after 4.9-rc1 (upon which this branch is > based), and one that will not show up in block/blk-flush.c. The

Re: [LSF/MM TOPIC] Un-addressable device memory and block/fs implications

On Tue, Dec 13, 2016 at 02:08:22PM -0800, Dave Hansen wrote: > On 12/13/2016 01:24 PM, Jerome Glisse wrote: > > > >>> > > From kernel point of view such memory is almost like any other, it > >>> > > has a struct page and most of the mm code is non the wiser, nor need > >>> > > to be about it. CPU

Re: [LSF/MM TOPIC] Un-addressable device memory and block/fs implications

On Wed, Dec 14, 2016 at 09:13:22AM +1100, Dave Chinner wrote: > On Tue, Dec 13, 2016 at 04:24:33PM -0500, Jerome Glisse wrote: > > On Wed, Dec 14, 2016 at 08:10:41AM +1100, Dave Chinner wrote: > > > On Tue, Dec 13, 2016 at 03:31:13PM -0500, Jerome Glisse wrote: > > > > On Wed, Dec 14, 2016 at

Re: [LSF/MM TOPIC] Un-addressable device memory and block/fs implications

On Tue, Dec 13, 2016 at 04:24:33PM -0500, Jerome Glisse wrote: > On Wed, Dec 14, 2016 at 08:10:41AM +1100, Dave Chinner wrote: > > On Tue, Dec 13, 2016 at 03:31:13PM -0500, Jerome Glisse wrote: > > > On Wed, Dec 14, 2016 at 07:15:15AM +1100, Dave Chinner wrote: > > > > On Tue, Dec 13, 2016 at

Re: [LSF/MM TOPIC] Un-addressable device memory and block/fs implications

On 12/13/2016 01:24 PM, Jerome Glisse wrote: > >>> > > From kernel point of view such memory is almost like any other, it >>> > > has a struct page and most of the mm code is non the wiser, nor need >>> > > to be about it. CPU access trigger a migration back to regular CPU >>> > > accessible

Re: [PATCHSET/RFC v2] blk-mq scheduling framework

On 12/13/2016 09:28 AM, Jens Axboe wrote: >>> No worries, ask away if you have questions. As you might have seen, it's >>> still a little bit of a moving target, but it's getting closer every >>> day. I'll post a v3 later today hopefully that will be a good fix point >>> for you. I'll need to add

Re: [LSF/MM TOPIC] Un-addressable device memory and block/fs implications

On Wed, Dec 14, 2016 at 08:10:41AM +1100, Dave Chinner wrote: > On Tue, Dec 13, 2016 at 03:31:13PM -0500, Jerome Glisse wrote: > > On Wed, Dec 14, 2016 at 07:15:15AM +1100, Dave Chinner wrote: > > > On Tue, Dec 13, 2016 at 01:15:11PM -0500, Jerome Glisse wrote: > > > > I would like to discuss

Re: [LSF/MM TOPIC] Un-addressable device memory and block/fs implications

On Tue, Dec 13, 2016 at 03:31:13PM -0500, Jerome Glisse wrote: > On Wed, Dec 14, 2016 at 07:15:15AM +1100, Dave Chinner wrote: > > On Tue, Dec 13, 2016 at 01:15:11PM -0500, Jerome Glisse wrote: > > > I would like to discuss un-addressable device memory in the context of > > > filesystem and block

Re: [LSF/MM TOPIC] Un-addressable device memory and block/fs implications

On Wed, Dec 14, 2016 at 07:15:15AM +1100, Dave Chinner wrote: > On Tue, Dec 13, 2016 at 01:15:11PM -0500, Jerome Glisse wrote: > > I would like to discuss un-addressable device memory in the context of > > filesystem and block device. Specificaly how to handle write-back, read, > > ... when a

Re: [LSF/MM TOPIC] Un-addressable device memory and block/fs implications

On 12/13/2016 12:01 PM, James Bottomley wrote: >> > Second aspect is that even if memory i am dealing with is un >> > -addressable i still have struct page for it and i want to be able to >> > use regular page migration. > Tmem keeps a struct page ... what's the problem with page migration? > the

Re: [LSF/MM TOPIC] Un-addressable device memory and block/fs implications

On Tue, Dec 13, 2016 at 12:01:04PM -0800, James Bottomley wrote: > On Tue, 2016-12-13 at 13:55 -0500, Jerome Glisse wrote: > > On Tue, Dec 13, 2016 at 10:20:52AM -0800, James Bottomley wrote: > > > On Tue, 2016-12-13 at 13:15 -0500, Jerome Glisse wrote: > > > > I would like to discuss

Re: [GIT PULL] Block core changes for 4.10

On 12/11/2016 06:52 PM, Jens Axboe wrote: > Note that this pull will throw 3 trivial merge conflicts, since we had > patches that went into mainline after 4.9-rc1 (upon which this branch is > based), and one that will not show up in block/blk-flush.c. The latter > is due to a fix that went in for

Re: [LSF/MM TOPIC] Un-addressable device memory and block/fs implications

On Tue, Dec 13, 2016 at 01:15:11PM -0500, Jerome Glisse wrote: > I would like to discuss un-addressable device memory in the context of > filesystem and block device. Specificaly how to handle write-back, read, > ... when a filesystem page is migrated to device memory that CPU can not > access.

Re: [LSF/MM TOPIC] Un-addressable device memory and block/fs implications

On Tue, 2016-12-13 at 13:55 -0500, Jerome Glisse wrote: > On Tue, Dec 13, 2016 at 10:20:52AM -0800, James Bottomley wrote: > > On Tue, 2016-12-13 at 13:15 -0500, Jerome Glisse wrote: > > > I would like to discuss un-addressable device memory in the > > > context > > > of filesystem and block

Re: [LSF/MM TOPIC] Un-addressable device memory and block/fs implications

On Tue, Dec 13, 2016 at 10:20:52AM -0800, James Bottomley wrote: > On Tue, 2016-12-13 at 13:15 -0500, Jerome Glisse wrote: > > I would like to discuss un-addressable device memory in the context > > of filesystem and block device. Specificaly how to handle write-back, > > read, ... when a

Re: [LSF/MM TOPIC] Un-addressable device memory and block/fs implications

On Tue, 2016-12-13 at 13:15 -0500, Jerome Glisse wrote: > I would like to discuss un-addressable device memory in the context > of filesystem and block device. Specificaly how to handle write-back, > read, ... when a filesystem page is migrated to device memory that > CPU can not access. > > I

[LSF/MM TOPIC] Un-addressable device memory and block/fs implications

I would like to discuss un-addressable device memory in the context of filesystem and block device. Specificaly how to handle write-back, read, ... when a filesystem page is migrated to device memory that CPU can not access. I intend to post a patchset leveraging the same idea as the existing

Re: [PATCHSET/RFC v2] blk-mq scheduling framework

On 12/13/2016 09:15 AM, Paolo Valente wrote: > >> Il giorno 13 dic 2016, alle ore 16:17, Jens Axboe ha scritto: >> >> On Tue, Dec 13 2016, Paolo Valente wrote: >>> Il giorno 08 dic 2016, alle ore 21:13, Jens Axboe ha scritto: As a followup to

extend bi_size to unsigned long ?

Hi linux-block and linux-nvme lists, Recently when I work on md-raid0 DISCARD optimization, I found the maximum DISCARD bio length that raid0_make_request() receives is 8388608 sectors. I find it is because of the limitation of bi_size, which is unsigned int and 32 bits length. A 32 bits bi_size

Re: [PATCH 5/7] blk-mq-sched: add framework for MQ capable IO schedulers

On Tue, Dec 13 2016, Bart Van Assche wrote: > On 12/08/2016 09:13 PM, Jens Axboe wrote: > >+static inline void blk_mq_sched_put_request(struct request *rq) > >+{ > >+struct request_queue *q = rq->q; > >+struct elevator_queue *e = q->elevator; > >+ > >+if (e &&

Re: [PATCHSET/RFC v2] blk-mq scheduling framework

On Tue, Dec 13 2016, Paolo Valente wrote: > > > Il giorno 08 dic 2016, alle ore 21:13, Jens Axboe ha scritto: > > > > As a followup to this posting from yesterday: > > > > https://marc.info/?l=linux-block=148115232806065=2 > > > > this is version 2. I wanted to post a new one

Re: [PATCH 7/7] blk-mq-sched: allow setting of default IO scheduler

On 12/13/2016 03:13 AM, Bart Van Assche wrote: > On 12/08/2016 09:13 PM, Jens Axboe wrote: >> +config DEFAULT_MQ_IOSCHED >> +string >> +default "mq-deadline" if DEFAULT_MQ_DEADLINE >> +default "none" if DEFAULT_MQ_NONE >> + >> endmenu >> >> +config MQ_IOSCHED_ONLY_SQ >> +bool

extend bi_size to unsigned long ?

Hi linux-block and linux-nvme lists, Recently when I work on md-raid0 DISCARD optimization, I found the maximum DISCARD bio length that raid0_make_request() receives is 8388608 sectors. I find it is because of the limitation of bi_size, which is unsigned int and 32 bits length. A 32 bits bi_size

Re: [PATCH 6/7] mq-deadline: add blk-mq adaptation of the deadline IO scheduler

On 12/08/2016 09:13 PM, Jens Axboe wrote: +static int dd_init_queue(struct request_queue *q, struct elevator_type *e) +{ + struct deadline_data *dd; + struct elevator_queue *eq; + + eq = elevator_alloc(q, e); + if (!eq) + return -ENOMEM; + + dd =

Re: [PATCH 7/7] blk-mq-sched: allow setting of default IO scheduler

On 12/08/2016 09:13 PM, Jens Axboe wrote: +config DEFAULT_MQ_IOSCHED + string + default "mq-deadline" if DEFAULT_MQ_DEADLINE + default "none" if DEFAULT_MQ_NONE + endmenu +config MQ_IOSCHED_ONLY_SQ + bool "Enable blk-mq IO scheduler only for single queue devices" +

Re: [PATCH 2/7] blk-mq: abstract out blk_mq_dispatch_rq_list() helper

On 12/13/2016 10:18 AM, Ritesh Harjani wrote: On 12/9/2016 1:43 AM, Jens Axboe wrote: +if (!list_empty_careful(>dispatch)) { +spin_lock(>lock); +if (!list_empty(>dispatch)) list_splice_init already checks for list_empty. So this may be redundant. Please check. Hello

Re: [PATCHSET/RFC v2] blk-mq scheduling framework

> Il giorno 08 dic 2016, alle ore 21:13, Jens Axboe ha scritto: > > As a followup to this posting from yesterday: > > https://marc.info/?l=linux-block=148115232806065=2 > > this is version 2. I wanted to post a new one fairly quickly, as there > ended up being a number of

Re: [PATCH 2/7] blk-mq: abstract out blk_mq_dispatch_rq_list() helper

Minor comments. On 12/9/2016 1:43 AM, Jens Axboe wrote: Takes a list of requests, and dispatches it. Moves any residual requests to the dispatch list. Signed-off-by: Jens Axboe --- block/blk-mq.c | 85 -- block/blk-mq.h |

Re: [PATCH 2/7] blk-mq: abstract out blk_mq_dispatch_rq_list() helper

On 12/08/2016 09:13 PM, Jens Axboe wrote: +static void blk_mq_process_rq_list(struct blk_mq_hw_ctx *hctx) +{ + LIST_HEAD(rq_list); + LIST_HEAD(driver_list); Hello Jens, driver_list is not used in this function so please consider removing that variable from

Re: [PATCH 1/7] blk-mq: add blk_mq_start_stopped_hw_queue()

On 12/08/2016 09:13 PM, Jens Axboe wrote: We have a variant for all hardware queues, but not one for a single hardware queue. Reviewed-by: Bart Van Assche -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to