All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	"ksummit-discuss@lists.linux-foundation.org"
	<ksummit-discuss@lists.linux-foundation.org>,
	Greg KH <gregkh@linuxfoundation.org>, Jens Axboe <axboe@fb.com>,
	Hannes Reinecke <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: Wed, 21 Sep 2016 14:51:21 +0100	[thread overview]
Message-ID: <CACxGe6t1JpdTxB88G75Y0wZkFHEr2tnG7DvYGvGk3gnm6oLpng@mail.gmail.com> (raw)
In-Reply-To: <1474054593.2353.76.camel@HansenPartnership.com>

On Fri, Sep 16, 2016 at 8:36 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> 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.
>  And for those 10, there were likely another 10 who didn't get invited
> who wanted the chance to express an opinion.  Realistically, this is
> why we no-longer do technical discussions at KS: audience too broad and
> not enough specific subject matter experts.
>
> However, nothing says you can't have a discussion in the hallway if
> you're already going.

Maybe we can set aside a slot or too for smaller scale BoF sessions?
If there are other topics in this vein, it would be good to have a
list of them ahead of time. I've been considering a BoF related to our
device model for example.

g.

  parent reply	other threads:[~2016-09-21 13:51 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
2016-09-17 10:31         ` Linus Walleij
2016-09-21 13:51         ` Grant Likely [this message]
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=CACxGe6t1JpdTxB88G75Y0wZkFHEr2tnG7DvYGvGk3gnm6oLpng@mail.gmail.com \
    --to=grant.likely@secretlab.ca \
    --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=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.