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 k
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 h
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 p
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
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
> gi
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
> su
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] at
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 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 fi
> -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 ha
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 sen
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 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
> > > ind
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
> > > individu
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 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 acce
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 interru
18 matches
Mail list logo
