On Mon, Oct 06, 2014 at 02:24:46PM +0100, Alexander Gordeev wrote:
> On Mon, Oct 06, 2014 at 08:58:17AM -0400, Tejun Heo wrote:
> > I don't think we'd be able to move libata handling to block softirq
> > and probably end up just doing it from the irq context. Anyways, as
> > long as you're gonna
On Mon, Oct 06, 2014 at 08:58:17AM -0400, Tejun Heo wrote:
> I don't think we'd be able to move libata handling to block softirq
> and probably end up just doing it from the irq context. Anyways, as
> long as you're gonna keep working on it, I have no objection to the
> proposed changes. Do you
Hello, Alexander.
On Mon, Oct 06, 2014 at 08:27:11AM +0100, Alexander Gordeev wrote:
> > Why are we bouncing the context twice?
>
> I *did* consider moving the threaded handler code to the softirq part.
> I just wanted to get updates in stages: to address hardware interrupts
> latency first and
On Sun, Oct 05, 2014 at 12:16:46PM -0400, Tejun Heo wrote:
> I think the thing which bothers me is that due to softirq we end up
> bouncing the context twice. IRQ schedules threaded IRQ handler after
> doing minimal amount of work. The threaded IRQ handler gets scheduled
> and again it doesn't
On Sun, Oct 05, 2014 at 12:16:46PM -0400, Tejun Heo wrote:
I think the thing which bothers me is that due to softirq we end up
bouncing the context twice. IRQ schedules threaded IRQ handler after
doing minimal amount of work. The threaded IRQ handler gets scheduled
and again it doesn't do
Hello, Alexander.
On Mon, Oct 06, 2014 at 08:27:11AM +0100, Alexander Gordeev wrote:
Why are we bouncing the context twice?
I *did* consider moving the threaded handler code to the softirq part.
I just wanted to get updates in stages: to address hardware interrupts
latency first and
On Mon, Oct 06, 2014 at 08:58:17AM -0400, Tejun Heo wrote:
I don't think we'd be able to move libata handling to block softirq
and probably end up just doing it from the irq context. Anyways, as
long as you're gonna keep working on it, I have no objection to the
proposed changes. Do you have
On Mon, Oct 06, 2014 at 02:24:46PM +0100, Alexander Gordeev wrote:
On Mon, Oct 06, 2014 at 08:58:17AM -0400, Tejun Heo wrote:
I don't think we'd be able to move libata handling to block softirq
and probably end up just doing it from the irq context. Anyways, as
long as you're gonna keep
A bit of addition.
On Sat, Oct 04, 2014 at 10:23:11PM -0400, Tejun Heo wrote:
> Hmmm so, AFAICS, there's no real pros or cons of going either way,
> right? The only thing which could be different is possibly slightly
> lower latency in servicing other IRQs or RT tasks on the same CPU but
>
A bit of addition.
On Sat, Oct 04, 2014 at 10:23:11PM -0400, Tejun Heo wrote:
Hmmm so, AFAICS, there's no real pros or cons of going either way,
right? The only thing which could be different is possibly slightly
lower latency in servicing other IRQs or RT tasks on the same CPU but
given
Hey, Alexander.
On Wed, Oct 01, 2014 at 04:31:15PM +0100, Alexander Gordeev wrote:
> As of your concern wrt threaded handler invocation overhead - I am
> not quite sure here, but if SCHED_FIFO policy (the handler runs with)
> makes the difference? Anyway, as said above the overall IO does not
>
Hey, Alexander.
On Wed, Oct 01, 2014 at 04:31:15PM +0100, Alexander Gordeev wrote:
As of your concern wrt threaded handler invocation overhead - I am
not quite sure here, but if SCHED_FIFO policy (the handler runs with)
makes the difference? Anyway, as said above the overall IO does not
On Wed, Oct 01, 2014 at 04:31:14PM +0100, Alexander Gordeev wrote:
> I am attaching excerpts from some new perf tests I have done (this
Attaching :)
--
Regards,
Alexander Gordeev
agord...@redhat.com
0.04% dd [kernel.kallsyms] [k] ata_std_qc_defer
0.04% dd [kernel.kallsyms] [k]
On Wed, Sep 24, 2014 at 10:39:13AM -0400, Tejun Heo wrote:
> Hello, Alexander.
>
> On Wed, Sep 24, 2014 at 03:08:44PM +0100, Alexander Gordeev wrote:
> > > Hmmm, how would the whole system benefit from it if there's only
> > > single device? Each individual servicing of the interrupt does more
>
On Wed, Sep 24, 2014 at 10:39:13AM -0400, Tejun Heo wrote:
Hello, Alexander.
On Wed, Sep 24, 2014 at 03:08:44PM +0100, Alexander Gordeev wrote:
Hmmm, how would the whole system benefit from it if there's only
single device? Each individual servicing of the interrupt does more
now
On Wed, Oct 01, 2014 at 04:31:14PM +0100, Alexander Gordeev wrote:
I am attaching excerpts from some new perf tests I have done (this
Attaching :)
--
Regards,
Alexander Gordeev
agord...@redhat.com
0.04% dd [kernel.kallsyms] [k] ata_std_qc_defer
0.04% dd [kernel.kallsyms] [k]
On Wed, Sep 24, 2014 at 03:59:07PM +0100, Alexander Gordeev wrote:
> On Wed, Sep 24, 2014 at 10:39:13AM -0400, Tejun Heo wrote:
> > Would it be possible for you compare threaded vs. unthreaded under
> > relatively heavy load?
>
> I will try, although not quite soon.
>
> In the meantime I could
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Tejun Heo
...
> The thing I don't get is why multiple MSI handling and this patchset
> are tied to threaded interrupt handling. Splitting locks don't
> necessarily
On Wed, Sep 24, 2014 at 10:39:13AM -0400, Tejun Heo wrote:
> Would it be possible for you compare threaded vs. unthreaded under
> relatively heavy load?
I will try, although not quite soon.
In the meantime I could fix and resend patches 1,2,3 and 6 as
they are not related to this topic. Makes
Hello, Alexander.
On Wed, Sep 24, 2014 at 03:08:44PM +0100, Alexander Gordeev wrote:
> > Hmmm, how would the whole system benefit from it if there's only
> > single device? Each individual servicing of the interrupt does more
> > now which includes scheduling which may end up adding to
On Wed, Sep 24, 2014 at 09:04:44AM -0400, Tejun Heo wrote:
> Hello, Alexander.
>
> On Wed, Sep 24, 2014 at 11:42:15AM +0100, Alexander Gordeev wrote:
> > On Tue, Sep 23, 2014 at 04:57:10PM -0400, Tejun Heo wrote:
> > > Hmmm... how does it affect single device operation tho? It does make
> > >
On Wed, Sep 24, 2014 at 08:27:12AM -0500, Chuck Ebbert wrote:
> I think he meant other, non-AHCI, interrupt handlers would benefit. A
> good test of this patch might be to stream 10Gb ethernet while also
> streaming writes to an AHCI device.
I'm a bit doubtful this'd make a noticeable difference.
On Wed, 24 Sep 2014 09:04:44 -0400
Tejun Heo wrote:
> Hello, Alexander.
>
> On Wed, Sep 24, 2014 at 11:42:15AM +0100, Alexander Gordeev wrote:
> > On Tue, Sep 23, 2014 at 04:57:10PM -0400, Tejun Heo wrote:
> > > Hmmm... how does it affect single device operation tho? It does make
> > >
Hello, Alexander.
On Wed, Sep 24, 2014 at 11:42:15AM +0100, Alexander Gordeev wrote:
> On Tue, Sep 23, 2014 at 04:57:10PM -0400, Tejun Heo wrote:
> > Hmmm... how does it affect single device operation tho? It does make
> > individual interrupt handling heavier, no?
>
> I think it is difficult
On Tue, Sep 23, 2014 at 04:57:10PM -0400, Tejun Heo wrote:
> Hmmm... how does it affect single device operation tho? It does make
> individual interrupt handling heavier, no?
I think it is difficult to assess "individual interrupt handling", since
it depends from both the hardware and device
On Tue, Sep 23, 2014 at 04:57:10PM -0400, Tejun Heo wrote:
Hmmm... how does it affect single device operation tho? It does make
individual interrupt handling heavier, no?
I think it is difficult to assess individual interrupt handling, since
it depends from both the hardware and device access
Hello, Alexander.
On Wed, Sep 24, 2014 at 11:42:15AM +0100, Alexander Gordeev wrote:
On Tue, Sep 23, 2014 at 04:57:10PM -0400, Tejun Heo wrote:
Hmmm... how does it affect single device operation tho? It does make
individual interrupt handling heavier, no?
I think it is difficult to
On Wed, 24 Sep 2014 09:04:44 -0400
Tejun Heo t...@kernel.org wrote:
Hello, Alexander.
On Wed, Sep 24, 2014 at 11:42:15AM +0100, Alexander Gordeev wrote:
On Tue, Sep 23, 2014 at 04:57:10PM -0400, Tejun Heo wrote:
Hmmm... how does it affect single device operation tho? It does make
On Wed, Sep 24, 2014 at 08:27:12AM -0500, Chuck Ebbert wrote:
I think he meant other, non-AHCI, interrupt handlers would benefit. A
good test of this patch might be to stream 10Gb ethernet while also
streaming writes to an AHCI device.
I'm a bit doubtful this'd make a noticeable difference.
On Wed, Sep 24, 2014 at 09:04:44AM -0400, Tejun Heo wrote:
Hello, Alexander.
On Wed, Sep 24, 2014 at 11:42:15AM +0100, Alexander Gordeev wrote:
On Tue, Sep 23, 2014 at 04:57:10PM -0400, Tejun Heo wrote:
Hmmm... how does it affect single device operation tho? It does make
individual
Hello, Alexander.
On Wed, Sep 24, 2014 at 03:08:44PM +0100, Alexander Gordeev wrote:
Hmmm, how would the whole system benefit from it if there's only
single device? Each individual servicing of the interrupt does more
now which includes scheduling which may end up adding to completion
On Wed, Sep 24, 2014 at 10:39:13AM -0400, Tejun Heo wrote:
Would it be possible for you compare threaded vs. unthreaded under
relatively heavy load?
I will try, although not quite soon.
In the meantime I could fix and resend patches 1,2,3 and 6 as
they are not related to this topic. Makes
-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Tejun Heo
...
The thing I don't get is why multiple MSI handling and this patchset
are tied to threaded interrupt handling. Splitting locks don't
necessarily have
On Wed, Sep 24, 2014 at 03:59:07PM +0100, Alexander Gordeev wrote:
On Wed, Sep 24, 2014 at 10:39:13AM -0400, Tejun Heo wrote:
Would it be possible for you compare threaded vs. unthreaded under
relatively heavy load?
I will try, although not quite soon.
In the meantime I could fix and
Hello, Alexander.
On Sun, Sep 21, 2014 at 03:19:28PM +0200, Alexander Gordeev wrote:
> Split interrupt service routine into hardware context handler
> and threaded context handler. That allows to protect ports with
> individual locks rather than with a single host-wide lock and
> move port
Hello, Alexander.
On Sun, Sep 21, 2014 at 03:19:28PM +0200, Alexander Gordeev wrote:
Split interrupt service routine into hardware context handler
and threaded context handler. That allows to protect ports with
individual locks rather than with a single host-wide lock and
move port interrupts
Split interrupt service routine into hardware context handler
and threaded context handler. That allows to protect ports with
individual locks rather than with a single host-wide lock and
move port interrupts handling out of the hardware interrupt
context.
Testing was done by transferring 8GB on
Split interrupt service routine into hardware context handler
and threaded context handler. That allows to protect ports with
individual locks rather than with a single host-wide lock and
move port interrupts handling out of the hardware interrupt
context.
Testing was done by transferring 8GB on
38 matches
Mail list logo
