On 09/23/2014 12:11 AM, Tejun Heo wrote:
> On Tue, Sep 23, 2014 at 08:09:06AM +0200, Christoph Hellwig wrote:
>> On Tue, Sep 23, 2014 at 02:01:41AM -0400, Tejun Heo wrote:
>>> On Tue, Sep 23, 2014 at 07:59:24AM +0200, Christoph Hellwig wrote:
"[PATCHSET percpu/for-3.18] percpu_ref: implement
rnel.org
> Subject: Re: boot stall regression due to blk-mq: use percpu_ref for mq usage
> count
>
> On Tue, Sep 23, 2014 at 08:09:06AM +0200, Christoph Hellwig wrote:
> > On Tue, Sep 23, 2014 at 02:01:41AM -0400, Tejun Heo wrote:
> > > On Tue, Sep 23, 2014
On Tue, Sep 23, 2014 at 08:09:06AM +0200, Christoph Hellwig wrote:
> On Tue, Sep 23, 2014 at 02:01:41AM -0400, Tejun Heo wrote:
> > On Tue, Sep 23, 2014 at 07:59:24AM +0200, Christoph Hellwig wrote:
> > > "[PATCHSET percpu/for-3.18] percpu_ref: implement
> > > switch_to_atomic/percpu()"
> > >
>
On Tue, Sep 23, 2014 at 02:01:41AM -0400, Tejun Heo wrote:
> On Tue, Sep 23, 2014 at 07:59:24AM +0200, Christoph Hellwig wrote:
> > "[PATCHSET percpu/for-3.18] percpu_ref: implement switch_to_atomic/percpu()"
> >
> > looks way to big for 3.17, and the regression was introduced in the 3.17
> >
On Tue, Sep 23, 2014 at 02:01:41AM -0400, Tejun Heo wrote:
> On Tue, Sep 23, 2014 at 07:59:24AM +0200, Christoph Hellwig wrote:
> > "[PATCHSET percpu/for-3.18] percpu_ref: implement switch_to_atomic/percpu()"
> >
> > looks way to big for 3.17, and the regression was introduced in the 3.17
> >
On Tue, Sep 23, 2014 at 07:59:24AM +0200, Christoph Hellwig wrote:
> "[PATCHSET percpu/for-3.18] percpu_ref: implement switch_to_atomic/percpu()"
>
> looks way to big for 3.17, and the regression was introduced in the 3.17
> merge window. I'm not sure what was broken before, but it defintively
>
On Tue, Sep 23, 2014 at 01:56:48AM -0400, Tejun Heo wrote:
> On Tue, Sep 23, 2014 at 07:55:54AM +0200, Christoph Hellwig wrote:
> > Jens,
> >
> > can we simply get these commits reverted from now if there's no better
> > fix? I'd hate to have this boot stall in the first kernel with blk-mq
> >
On Tue, Sep 23, 2014 at 01:56:48AM -0400, Tejun Heo wrote:
On Tue, Sep 23, 2014 at 07:55:54AM +0200, Christoph Hellwig wrote:
Jens,
can we simply get these commits reverted from now if there's no better
fix? I'd hate to have this boot stall in the first kernel with blk-mq
support for
On Tue, Sep 23, 2014 at 07:59:24AM +0200, Christoph Hellwig wrote:
[PATCHSET percpu/for-3.18] percpu_ref: implement switch_to_atomic/percpu()
looks way to big for 3.17, and the regression was introduced in the 3.17
merge window. I'm not sure what was broken before, but it defintively
On Tue, Sep 23, 2014 at 02:01:41AM -0400, Tejun Heo wrote:
On Tue, Sep 23, 2014 at 07:59:24AM +0200, Christoph Hellwig wrote:
[PATCHSET percpu/for-3.18] percpu_ref: implement switch_to_atomic/percpu()
looks way to big for 3.17, and the regression was introduced in the 3.17
merge window.
On Tue, Sep 23, 2014 at 02:01:41AM -0400, Tejun Heo wrote:
On Tue, Sep 23, 2014 at 07:59:24AM +0200, Christoph Hellwig wrote:
[PATCHSET percpu/for-3.18] percpu_ref: implement switch_to_atomic/percpu()
looks way to big for 3.17, and the regression was introduced in the 3.17
merge window.
On Tue, Sep 23, 2014 at 08:09:06AM +0200, Christoph Hellwig wrote:
On Tue, Sep 23, 2014 at 02:01:41AM -0400, Tejun Heo wrote:
On Tue, Sep 23, 2014 at 07:59:24AM +0200, Christoph Hellwig wrote:
[PATCHSET percpu/for-3.18] percpu_ref: implement
switch_to_atomic/percpu()
looks way to
: boot stall regression due to blk-mq: use percpu_ref for mq usage
count
On Tue, Sep 23, 2014 at 08:09:06AM +0200, Christoph Hellwig wrote:
On Tue, Sep 23, 2014 at 02:01:41AM -0400, Tejun Heo wrote:
On Tue, Sep 23, 2014 at 07:59:24AM +0200, Christoph Hellwig wrote:
[PATCHSET percpu/for-3.18
On 09/23/2014 12:11 AM, Tejun Heo wrote:
On Tue, Sep 23, 2014 at 08:09:06AM +0200, Christoph Hellwig wrote:
On Tue, Sep 23, 2014 at 02:01:41AM -0400, Tejun Heo wrote:
On Tue, Sep 23, 2014 at 07:59:24AM +0200, Christoph Hellwig wrote:
[PATCHSET percpu/for-3.18] percpu_ref: implement
On Tue, Sep 23, 2014 at 01:56:48AM -0400, Tejun Heo wrote:
> On Tue, Sep 23, 2014 at 07:55:54AM +0200, Christoph Hellwig wrote:
> > Jens,
> >
> > can we simply get these commits reverted from now if there's no better
> > fix? I'd hate to have this boot stall in the first kernel with blk-mq
> >
On Tue, Sep 23, 2014 at 07:55:54AM +0200, Christoph Hellwig wrote:
> Jens,
>
> can we simply get these commits reverted from now if there's no better
> fix? I'd hate to have this boot stall in the first kernel with blk-mq
> support for scsi.
Patches going out right now.
Thanks.
--
tejun
--
Jens,
can we simply get these commits reverted from now if there's no better
fix? I'd hate to have this boot stall in the first kernel with blk-mq
support for scsi.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Jens,
can we simply get these commits reverted from now if there's no better
fix? I'd hate to have this boot stall in the first kernel with blk-mq
support for scsi.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
On Tue, Sep 23, 2014 at 07:55:54AM +0200, Christoph Hellwig wrote:
Jens,
can we simply get these commits reverted from now if there's no better
fix? I'd hate to have this boot stall in the first kernel with blk-mq
support for scsi.
Patches going out right now.
Thanks.
--
tejun
--
To
On Tue, Sep 23, 2014 at 01:56:48AM -0400, Tejun Heo wrote:
On Tue, Sep 23, 2014 at 07:55:54AM +0200, Christoph Hellwig wrote:
Jens,
can we simply get these commits reverted from now if there's no better
fix? I'd hate to have this boot stall in the first kernel with blk-mq
support for
On 09/19/2014 05:38 AM, Christoph Hellwig wrote:
> Hi Jens, hi Tejun,
>
> I've seen multi-second boot stalls in one of my KVM setups during
> the initial scsi scan:
>
> [0.949892] scsi host0: Virtio SCSI HBA
> [1.007864] scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK1.1.
>
Hi Jens, hi Tejun,
I've seen multi-second boot stalls in one of my KVM setups during
the initial scsi scan:
[0.949892] scsi host0: Virtio SCSI HBA
[1.007864] scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK1.1.
PQ: 0 ANSI: 5
[1.021299] scsi 0:0:1:0: Direct-Access QEMU
Hi Jens, hi Tejun,
I've seen multi-second boot stalls in one of my KVM setups during
the initial scsi scan:
[0.949892] scsi host0: Virtio SCSI HBA
[1.007864] scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK1.1.
PQ: 0 ANSI: 5
[1.021299] scsi 0:0:1:0: Direct-Access QEMU
On 09/19/2014 05:38 AM, Christoph Hellwig wrote:
Hi Jens, hi Tejun,
I've seen multi-second boot stalls in one of my KVM setups during
the initial scsi scan:
[0.949892] scsi host0: Virtio SCSI HBA
[1.007864] scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK1.1.
PQ: 0
24 matches
Mail list logo