On 02/25/2017 11:17 AM, h...@lst.de wrote:
> On Fri, Feb 24, 2017 at 01:22:42PM -0700, Jens Axboe wrote:
>> Bart, I pushed a fix here:
>>
>> http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus&id=61febef40bfe8ab68259d8545257686e8a0d91d1
>
> Yeah, this looks fine to me. It was broken on blk-
On Fri, Feb 24, 2017 at 01:22:42PM -0700, Jens Axboe wrote:
> Bart, I pushed a fix here:
>
> http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus&id=61febef40bfe8ab68259d8545257686e8a0d91d1
Yeah, this looks fine to me. It was broken on blk-mq before, but
basically impossible to hit. I wond
On Fri, 2017-02-24 at 13:22 -0700, Jens Axboe wrote:
> Bart, I pushed a fix here:
>
> http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus&id=61febef40bfe8ab68259d8545257686e8a0d91d1
Hello Jens,
The same test passes against the kernel I obtained by merging your for-linus
branch with the sam
On 02/24/2017 01:00 PM, Jens Axboe wrote:
> On 02/24/2017 12:43 PM, Linus Torvalds wrote:
>> On Fri, Feb 24, 2017 at 9:39 AM, Bart Van Assche
>> wrote:
>>>
>>> So the crash is caused by an attempt to dereference address
>>> 0x6b6b6b6b6b6b6b6b
>>> at offset 0x270. I think this means the crash is c
On 02/24/2017 12:43 PM, Linus Torvalds wrote:
> On Fri, Feb 24, 2017 at 9:39 AM, Bart Van Assche
> wrote:
>>
>> So the crash is caused by an attempt to dereference address
>> 0x6b6b6b6b6b6b6b6b
>> at offset 0x270. I think this means the crash is caused by a use-after-free.
>
> Yeah, that's POISO
On Fri, Feb 24, 2017 at 9:39 AM, Bart Van Assche
wrote:
>
> So the crash is caused by an attempt to dereference address 0x6b6b6b6b6b6b6b6b
> at offset 0x270. I think this means the crash is caused by a use-after-free.
Yeah, that's POISON_FREE, and that might explain why you see crashes
that other
On 02/24/2017 10:39 AM, Bart Van Assche wrote:
> On Mon, 2017-02-20 at 09:32 -0700, Jens Axboe wrote:
>> On 02/20/2017 09:16 AM, Bart Van Assche wrote:
>>> On 02/19/2017 11:35 PM, Christoph Hellwig wrote:
On Sun, Feb 19, 2017 at 06:15:41PM -0700, Jens Axboe wrote:
> That said, we will look
On Mon, 2017-02-20 at 09:32 -0700, Jens Axboe wrote:
> On 02/20/2017 09:16 AM, Bart Van Assche wrote:
> > On 02/19/2017 11:35 PM, Christoph Hellwig wrote:
> > > On Sun, Feb 19, 2017 at 06:15:41PM -0700, Jens Axboe wrote:
> > > > That said, we will look into this again, of course. Christoph, any ide
On Wed, Feb 22, 2017 at 1:50 PM, Markus Trippelsdorf
wrote:
>
> 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?
Jens already said that
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 con
On 02/22/2017 02:50 PM, Markus Trippelsdorf wrote:
> 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
On 02/22/2017 12:04 PM, Linus Torvalds wrote:
> On Wed, Feb 22, 2017 at 10:58 AM, Jens Axboe wrote:
>> On 02/22/2017 11:56 AM, Linus Torvalds wrote:
>>
>> 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 defa
On Wed, Feb 22, 2017 at 10:58 AM, Jens Axboe wrote:
> On 02/22/2017 11:56 AM, Linus Torvalds wrote:
>
> 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 sc
On 02/22/2017 11:56 AM, Linus Torvalds wrote:
> On Wed, Feb 22, 2017 at 10:52 AM, Jens Axboe wrote:
>>>
>>> It's that simple.
>>
>> No, it's not that simple at all. Fact is, some optimizations make sense
>> for some workloads, and some do not.
>
> Are you even listening?
>
> I'm saying no user c
On Wed, Feb 22, 2017 at 10:52 AM, Jens Axboe wrote:
>>
>> It's that simple.
>
> No, it's not that simple at all. Fact is, some optimizations make sense
> for some workloads, and some do not.
Are you even listening?
I'm saying no user can ever give a sane answer to your question. The
question is
On Wed, Feb 22, 2017 at 10:41 AM, Jens Axboe wrote:
>
> The fact is that we have two different sets, until we can yank
> the old ones. So I can't just ask one question, since the sets
> aren't identical.
Bullshit.
I'm, saying: rip out the question ENTIRELY. For *both* cases.
If you cannot yours
On 02/22/2017 11:45 AM, Linus Torvalds wrote:
> On Wed, Feb 22, 2017 at 10:41 AM, Jens Axboe wrote:
>>
>> The fact is that we have two different sets, until we can yank
>> the old ones. So I can't just ask one question, since the sets
>> aren't identical.
>
> Bullshit.
>
> I'm, saying: rip out t
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
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.
If it's a config option about "do I have a particular piece of
hard
On 02/22/2017 11:26 AM, Linus Torvalds wrote:
> On Wed, Feb 22, 2017 at 10:14 AM, Jens Axboe wrote:
>>
>> What do you mean by "the regular IO scheduler"? These are different
>> schedulers.
>
> Not to the user they aren't.
>
> If the user already answered once about the IO schedulers, we damn
> w
On Wed, Feb 22, 2017 at 10:14 AM, Jens Axboe wrote:
>
> What do you mean by "the regular IO scheduler"? These are different
> schedulers.
Not to the user they aren't.
If the user already answered once about the IO schedulers, we damn
well shouldn't ask again abotu another small implementaiton de
On 02/21/2017 04:23 PM, Linus Torvalds wrote:
> On Tue, Feb 21, 2017 at 3:15 PM, Jens Axboe wrote:
>>
>> But under a device managed by blk-mq, that device exposes a number of
>> hardware queues. For older style devices, that number is typically 1
>> (single queue).
>
> ... but why would this ever
On Tue, Feb 21, 2017 at 3:15 PM, Jens Axboe wrote:
>
> But under a device managed by blk-mq, that device exposes a number of
> hardware queues. For older style devices, that number is typically 1
> (single queue).
... but why would this ever be different from the normal IO scheduler?
IOW, what m
On 02/21/2017 04:02 PM, Linus Torvalds wrote:
> Hmm. The new config options are incomprehensible and their help
> messages don't actually help.
>
> So can you fill in the blanks on what
>
> Default single-queue blk-mq I/O scheduler
> Default multi-queue blk-mq I/O scheduler
>
> config option
Hmm. The new config options are incomprehensible and their help
messages don't actually help.
So can you fill in the blanks on what
Default single-queue blk-mq I/O scheduler
Default multi-queue blk-mq I/O scheduler
config options mean, and why they default to none?
The config phase of the k
On 02/21/2017 12:11 PM, Linus Torvalds wrote:
> On Sun, Feb 19, 2017 at 4:10 PM, Jens Axboe wrote:
>>
>> Please pull! Either this pre-merged branch:
>>
>> git://git.kernel.dk/linux-block.git for-4.11/linus-merge-signed
>>
>> or
>>
>> git://git.kernel.dk/linux-block.git for-4.11/block-signed
>>
On Sun, Feb 19, 2017 at 4:10 PM, Jens Axboe wrote:
>
> Please pull! Either this pre-merged branch:
>
> git://git.kernel.dk/linux-block.git for-4.11/linus-merge-signed
>
> or
>
> git://git.kernel.dk/linux-block.git for-4.11/block-signed
> git://git.kernel.dk/linux-block.git for-4.11/next-sign
On 02/20/2017 08:32 AM, Jens Axboe wrote:
> Bart, since you are the only one that can reproduce this, can you just bisect
> your way through that series?
Hello Jens,
I will do that as soon as I'm back in the office (later this week).
Bart.
On 02/20/2017 09:16 AM, Bart Van Assche wrote:
> On 02/19/2017 11:35 PM, Christoph Hellwig wrote:
>> On Sun, Feb 19, 2017 at 06:15:41PM -0700, Jens Axboe wrote:
>>> That said, we will look into this again, of course. Christoph, any idea?
>>
>> No idea really - this seems so far away from the code t
On 02/19/2017 11:35 PM, Christoph Hellwig wrote:
> On Sun, Feb 19, 2017 at 06:15:41PM -0700, Jens Axboe wrote:
>> That said, we will look into this again, of course. Christoph, any idea?
>
> No idea really - this seems so far away from the code touched, and there
> are no obvious signs for a memor
On Sun, Feb 19, 2017 at 06:15:41PM -0700, Jens Axboe wrote:
> I don't think that's a regression in this series, it just triggers more easily
> with this series. The BLOCK_PC removal fixes aren't touching device life times
> at all.
Yes.
> That said, we will look into this again, of course. Christ
On 02/19/2017 07:59 PM, Jens Axboe wrote:
> On 02/19/2017 07:12 PM, James Bottomley wrote:
>> On Sun, 2017-02-19 at 18:15 -0700, Jens Axboe wrote:
>>> On 02/19/2017 06:09 PM, Bart Van Assche wrote:
On 02/19/2017 04:11 PM, Jens Axboe wrote:
> - Removal of the BLOCK_PC support in struct requ
On 02/19/2017 07:12 PM, James Bottomley wrote:
> On Sun, 2017-02-19 at 18:15 -0700, Jens Axboe wrote:
>> On 02/19/2017 06:09 PM, Bart Van Assche wrote:
>>> On 02/19/2017 04:11 PM, Jens Axboe wrote:
- Removal of the BLOCK_PC support in struct request, and
refactoring of
carrying SCS
On Sun, 2017-02-19 at 18:15 -0700, Jens Axboe wrote:
> On 02/19/2017 06:09 PM, Bart Van Assche wrote:
> > On 02/19/2017 04:11 PM, Jens Axboe wrote:
> > > - Removal of the BLOCK_PC support in struct request, and
> > > refactoring of
> > > carrying SCSI payloads in the block layer. This cleans up t
On 02/19/2017 06:09 PM, Bart Van Assche wrote:
> On 02/19/2017 04:11 PM, Jens Axboe wrote:
>> - Removal of the BLOCK_PC support in struct request, and refactoring of
>> carrying SCSI payloads in the block layer. This cleans up the code
>> nicely, and enables us to kill the SCSI specific parts o
On 02/19/2017 04:11 PM, Jens Axboe wrote:
> - Removal of the BLOCK_PC support in struct request, and refactoring of
> carrying SCSI payloads in the block layer. This cleans up the code
> nicely, and enables us to kill the SCSI specific parts of struct
> request, shrinking it down nicely. From
36 matches
Mail list logo
