All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Paolo Valente <paolo.valente@linaro.org>
Cc: Jens Axboe <axboe@fb.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	ksummit-discuss@lists.linux-foundation.org,
	Greg KH <gregkh@linuxfoundation.org>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	hare@suse.de, Tejun Heo <tj@kernel.org>,
	osandov@osandov.com, Christoph Hellwig <hch@lst.de>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Addressing long-standing high-latency problems related to I/O
Date: Mon, 19 Sep 2016 10:17:29 +0200	[thread overview]
Message-ID: <20160919081729.GB11487@quack2.suse.cz> (raw)
In-Reply-To: <7979CF12-3A19-43F0-90AE-C4264B67FC77@linaro.org>

On Fri 16-09-16 22:13:44, Paolo Valente wrote:
> > Il giorno 16 set 2016, alle ore 21:36, James Bottomley <James.Bottomley@HansenPartnership.com> ha scritto:
> > 
> > On Fri, 2016-09-16 at 20:48 +0200, Paolo Valente wrote:
> >>> Il giorno 16 set 2016, alle ore 17:15, James Bottomley <
> >>> James.Bottomley@HansenPartnership.com> ha scritto:
> >>> 
> >>> On Fri, 2016-09-16 at 10:24 +0200, Greg KH wrote:
> >>>> On Fri, Sep 16, 2016 at 09:55:45AM +0200, Paolo Valente wrote:
> >>>>> Linux systems suffers from long-standing high-latency problems, 
> >>>>> at system and application level, related to I/O.  For example,
> >>>>> they usually suffer from poor responsiveness--or even 
> >>>>> starvation, depending on the workload--while, e.g., one or more 
> >>>>> files are being read/written/copied.  On a similar note, 
> >>>>> background workloads may cause audio/video playback/streaming 
> >>>>> to stutter, even with long gaps. A lot of test results on this 
> >>>>> problem can be found here [1] (I'm citing only this resource 
> >>>>> just because I'm familiar with it, but evidence can be found in 
> >>>>> countless technical reports, scientific papers, forum
> >>>>> discussions, and so on).
> >>>> 
> >>>> <snip>
> >>>> 
> >>>> Isn't this a better topic for the Vault conference, or the 
> >>>> storage mini conference?
> >>> 
> >>> LSF/MM would be the place to have the technical discussion, yes. 
> >>> It will be in Cambridge (MA,USA not the real one) in the Feb/March
> >>> time frame in 2017.  Far more of the storage experts (who likely 
> >>> want to weigh in) will be present.
> >>> 
> >> 
> >> Perfect venue.  Just it would be a pity IMO to waste the opportunity
> >> of my being at KS with other people working on the components 
> >> involved in high-latency issues, and to delay by more months a 
> >> discussion on possible solutions.
> > 
> > OK, so the problem with a formal discussion of something like this at
> > KS is that of the 80 or so people in the room, likely only 10 have any
> > interest whatsoever, leading to intense boredom for the remaining 70.
> 
> No no, that would be scary to me, given the level of the audience!  I
> thought it would have been possible to arrange some sort of
> sub-discussions with limited groups (although maybe the fact the Linux
> still suffers from high latencies might somehow worry all people that
> care about the kernel).  I'm sorry, but this will be my first time at KS.

Yeah, so I'll be at KS and I'd be interested in this discussion. Actually
I expect to have Jens Axboe and Christoph Hellwig around as well which are
biggest blk-mq proponents so I think the most important people for the
discussion about what are the blockers for merging are there.

I agree that for a discussion about details of the scheduling algorithm
LSF/MM is a better venue but at least for a process discussion under which
conditions BFQ is mergeable KS is OK.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2016-09-19  8:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-16  7:55 [Ksummit-discuss] [TECH TOPIC] Addressing long-standing high-latency problems related to I/O Paolo Valente
2016-09-16  8:24 ` Greg KH
2016-09-16  8:59   ` Linus Walleij
2016-09-16  9:10     ` Bart Van Assche
2016-09-16 11:24       ` Linus Walleij
2016-09-16 11:46         ` Arnd Bergmann
2016-09-16 13:10           ` Paolo Valente
2016-09-16 13:36           ` Linus Walleij
2016-09-16 11:53         ` Bart Van Assche
2016-09-22  9:18     ` Ulf Hansson
2016-09-22 11:06       ` Linus Walleij
2016-09-16 15:15   ` James Bottomley
2016-09-16 18:48     ` Paolo Valente
2016-09-16 19:36       ` James Bottomley
2016-09-16 20:13         ` Paolo Valente
2016-09-19  8:17           ` Jan Kara [this message]
2016-09-17 10:31         ` Linus Walleij
2016-09-21 13:51         ` Grant Likely
2016-09-21 14:30 ` Bart Van Assche
2016-09-21 14:37   ` Paolo Valente

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160919081729.GB11487@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=axboe@fb.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=ksummit-discuss@lists.linux-foundation.org \
    --cc=osandov@osandov.com \
    --cc=paolo.valente@linaro.org \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.