On Mon, 2017-12-18 at 12:27 -0500, J. Bruce Fields wrote:
> I'd forgotten about throughput/latency tradeoffs--but
> couldn't those in theory be managed by runtime configuration of the
> sceduler, or at least some smaller hammer than turning off preemption
> entirely?
A kernel that has all of the g
On Mon, 2017-12-18 at 12:27 -0500, J. Bruce Fields wrote:
> On Mon, Dec 18, 2017 at 06:17:36PM +0100, Mike Galbraith wrote:
> > On Mon, 2017-12-18 at 18:00 +0100, Mike Galbraith wrote:
> > > On Mon, 2017-12-18 at 11:35 -0500, J. Bruce Fields wrote:
> > > >
> > > > Like I say, I don't really unders
On Mon, Dec 18, 2017 at 06:17:36PM +0100, Mike Galbraith wrote:
> On Mon, 2017-12-18 at 18:00 +0100, Mike Galbraith wrote:
> > On Mon, 2017-12-18 at 11:35 -0500, J. Bruce Fields wrote:
> > >
> > > Like I say, I don't really understand the issues here, so it's more a
> > > question than an objectio
On Mon, 2017-12-18 at 17:24 +, Trond Myklebust wrote:
> On Mon, 2017-12-18 at 18:00 +0100, Mike Galbraith wrote:
> > On Mon, 2017-12-18 at 11:35 -0500, J. Bruce Fields wrote:
> > >
> > > Like I say, I don't really understand the issues here, so it's more
> > > a
> > > question than an objectio
On Mon, 2017-12-18 at 18:00 +0100, Mike Galbraith wrote:
> On Mon, 2017-12-18 at 11:35 -0500, J. Bruce Fields wrote:
> >
> > Like I say, I don't really understand the issues here, so it's more
> > a
> > question than an objection (I don't know any reason a
> > cond_resched() would be bad ther
On Mon, 2017-12-18 at 18:00 +0100, Mike Galbraith wrote:
> On Mon, 2017-12-18 at 11:35 -0500, J. Bruce Fields wrote:
> >
> > Like I say, I don't really understand the issues here, so it's more a
> > question than an objection (I don't know any reason a
> > cond_resched() would be bad there.)
On Mon, 2017-12-18 at 11:35 -0500, J. Bruce Fields wrote:
>
> Like I say, I don't really understand the issues here, so it's more a
> question than an objection (I don't know any reason a
> cond_resched() would be bad there.)
Think of it this way: what all can be queued up behind that kworke
On Mon, 2017-12-18 at 11:35 -0500, J. Bruce Fields wrote:
>
> This probably just shows I don't understand the issues, but: isn't this
> the job of preemption?
If this were a PREEMPT kernel, yes, we'd check need_resched() on lock
release etc, but it's a PREEMPT_VOLUNTARY kernel.
-Mike
On Mon, Dec 18, 2017 at 04:31:52PM +0100, Mike Galbraith wrote:
> On Mon, 2017-12-18 at 16:17 +0100, Mike Galbraith wrote:
> >
> >
> > kworker/-74210.N.. 82893us : nfs_release_request
> > <-nfs_commit_release_pages
> > kworker/-74210.N.. 82893us : nfs_unlock_and_release_request
> >
On Mon, 2017-12-18 at 16:17 +0100, Mike Galbraith wrote:
>
>
> kworker/-74210.N.. 82893us : nfs_release_request
> <-nfs_commit_release_pages
> kworker/-74210.N.. 82893us : nfs_unlock_and_release_request
> <-nfs_commit_release_pages
> kworker/-74210.N.. 82893us : nfs_unlock_reque
Greetings,
While doing some generic scheduler latency testing, I stumbled onto
$subject. To reproduce this, I simply nfs mount my box, cd to one of
it's spinning rust buckets, and do bonnie -s . With nothing
else going on in the box, I've hit > 100ms wakeup latencies.
(nouveau apparently also t
11 matches
Mail list logo
