Re: EXT4 Oops (Re: [PATCH V15 06/22] mmc: block: Add blk-mq support)

2018-03-05 Thread Dmitry Osipenko
On 01.03.2018 19:04, Theodore Ts'o wrote: > On Thu, Mar 01, 2018 at 10:55:37AM +0200, Adrian Hunter wrote: >> On 27/02/18 11:28, Adrian Hunter wrote: >>> On 26/02/18 23:48, Dmitry Osipenko wrote: >>>> But still something is wrong... I've been getting occa

Re: EXT4 Oops (Re: [PATCH V15 06/22] mmc: block: Add blk-mq support)

2018-03-02 Thread Dmitry Osipenko
On 01.03.2018 23:20, Andreas Dilger wrote: > > On Mar 1, 2018, at 9:04 AM, Theodore Ts'o wrote: >> This doesn't seem to make sense; the PC is where we are currently >> executing, and LR is the "Link Register" where the flow of control >> will be returning after the current function returns, right

Re: [PATCH V15 06/22] mmc: block: Add blk-mq support

2018-02-27 Thread Dmitry Osipenko
On 27.02.2018 11:57, Linus Walleij wrote: > On Mon, Feb 26, 2018 at 10:48 PM, Dmitry Osipenko wrote: >> On 22.02.2018 20:54, Dmitry Osipenko wrote: >>> On 22.02.2018 10:42, Adrian Hunter wrote: > >>>> SDIO (unless it is a combo card) should be unaffected by

Re: [PATCH V15 06/22] mmc: block: Add blk-mq support

2018-02-26 Thread Dmitry Osipenko
On 22.02.2018 20:54, Dmitry Osipenko wrote: > On 22.02.2018 10:42, Adrian Hunter wrote: >> On 21/02/18 22:50, Dmitry Osipenko wrote: >>> On 29.11.2017 16:41, Adrian Hunter wrote: >>>> Define and use a blk-mq queue. Discards and flushes are processed >>&g

Re: [PATCH V15 06/22] mmc: block: Add blk-mq support

2018-02-22 Thread Dmitry Osipenko
On 22.02.2018 10:42, Adrian Hunter wrote: > On 21/02/18 22:50, Dmitry Osipenko wrote: >> On 29.11.2017 16:41, Adrian Hunter wrote: >>> Define and use a blk-mq queue. Discards and flushes are processed >>> synchronously, but reads and writes asynchronously. In or

Re: [PATCH V15 06/22] mmc: block: Add blk-mq support

2018-02-21 Thread Dmitry Osipenko
On 29.11.2017 16:41, Adrian Hunter wrote: > Define and use a blk-mq queue. Discards and flushes are processed > synchronously, but reads and writes asynchronously. In order to support > slow DMA unmapping, DMA unmapping is not done until after the next request > is started. That means the request i

Re: [PATCH V4 13/45] block: blk-merge: try to make front segments in full size

2018-01-10 Thread Dmitry Osipenko
On 10.01.2018 05:40, Ming Lei wrote: > On Tue, Jan 09, 2018 at 08:02:53PM +0300, Dmitry Osipenko wrote: >> On 09.01.2018 17:33, Ming Lei wrote: >>> On Tue, Jan 09, 2018 at 04:18:39PM +0300, Dmitry Osipenko wrote: >>>> On 09.01.2018 05:34, Ming Lei wrote: >>&g

Re: [PATCH V4 13/45] block: blk-merge: try to make front segments in full size

2018-01-09 Thread Dmitry Osipenko
On 09.01.2018 17:33, Ming Lei wrote: > On Tue, Jan 09, 2018 at 04:18:39PM +0300, Dmitry Osipenko wrote: >> On 09.01.2018 05:34, Ming Lei wrote: >>> On Tue, Jan 09, 2018 at 12:09:27AM +0300, Dmitry Osipenko wrote: >>>> On 18.12.2017 15:22, Ming Lei wrote: >>&g

Re: [PATCH V4 13/45] block: blk-merge: try to make front segments in full size

2018-01-09 Thread Dmitry Osipenko
On 09.01.2018 05:34, Ming Lei wrote: > On Tue, Jan 09, 2018 at 12:09:27AM +0300, Dmitry Osipenko wrote: >> On 18.12.2017 15:22, Ming Lei wrote: >>> When merging one bvec into segment, if the bvec is too big >>> to merge, current policy is to move the whole bvec i

Re: [PATCH V4 13/45] block: blk-merge: try to make front segments in full size

2018-01-08 Thread Dmitry Osipenko
On 18.12.2017 15:22, Ming Lei wrote: > When merging one bvec into segment, if the bvec is too big > to merge, current policy is to move the whole bvec into another > new segment. > > This patchset changes the policy into trying to maximize size of > front segments, that means in above situation, p