All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: akpm@linux-foundation.org, wfg@mail.ustc.edu.cn,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] remove throttle_vm_writeout()
Date: Thu, 04 Oct 2007 15:23:06 +0200	[thread overview]
Message-ID: <1191504186.22357.20.camel@twins> (raw)
In-Reply-To: <E1IdQJn-0002Cv-00@dorka.pomaz.szeredi.hu>

[-- Attachment #1: Type: text/plain, Size: 2191 bytes --]

On Thu, 2007-10-04 at 15:00 +0200, Miklos Szeredi wrote:
> > > 1) File backed pages -> file
> > > 
> > >   dirty + writeback count remains constant
> > > 
> > > 2) Anonymous pages -> swap
> > > 
> > >   writeback count increases, dirty balancing will hold back file
> > >   writeback in favor of swap
> > > 
> > > So the real question is: does case 2 need rate limiting, or is it OK
> > > to let the device queue fill with swap pages as fast as possible?
> > 
> > > Because balance_dirty_pages() maintains:
> > 
> >  nr_dirty + nr_unstable + nr_writeback < 
> > 	total_dirty + nr_cpus * ratelimit_pages
> > 
> > throttle_vm_writeout() _should_ not deadlock on that, unless you're
> > caught in the error term: nr_cpus * ratelimit_pages. 
> 
> And it does get caught on that in small memory machines.  This
> deadlock is easily reproducable on a 32MB UML instance.  

Ah, yes, for those that is indeed easily doable.

> I haven't yet
> tested with the per-bdi patches, but I don't think they make a
> difference in this case.

Correct, they would not.

> > Which can only happen when it is larger than 10% of dirty_thresh.
> > 
> > Which is even more unlikely since it doesn't account nr_dirty (as I
> > think it should).
> 
> I think nr_dirty is totally irrelevant.  Since we don't care about
> case 1), and in case 2) nr_dirty doesn't play any role.

Ah, but its correct to have since we compare against dirty_thresh, which
is defined to be a unit of nr_dirty + nr_unstable + nr_writeback. if we
take one of these out, then we get an undefined amount of space extra.

> > As for 2), yes I think having a limit on the total number of pages in
> > flight is a good thing.
> 
> Why?

for my swapping over network thingies I need to put a bound on the
amount of outgoing traffic in flight because that bounds the amount of
memory consumed by the sending side.

> > But that said, there might be better ways to do that.
> 
> Sure, if we do need to globally limit the number of under-writeback
> pages, then I think we need to do it independently of the dirty
> accounting.

It need not be global, it could be per BDI as well, but yes.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-10-04 13:23 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-04 12:25 [PATCH] remove throttle_vm_writeout() Miklos Szeredi
2007-10-04 12:25 ` Miklos Szeredi
2007-10-04 12:40 ` Peter Zijlstra
2007-10-04 13:00   ` Miklos Szeredi
2007-10-04 13:00     ` Miklos Szeredi
2007-10-04 13:23     ` Peter Zijlstra [this message]
2007-10-04 13:49       ` Miklos Szeredi
2007-10-04 13:49         ` Miklos Szeredi
2007-10-04 16:47         ` Peter Zijlstra
2007-10-04 16:47           ` Peter Zijlstra
2007-10-04 17:46           ` Andrew Morton
2007-10-04 17:46             ` Andrew Morton
2007-10-04 18:10             ` Peter Zijlstra
2007-10-04 18:10               ` Peter Zijlstra
2007-10-04 18:54               ` Andrew Morton
2007-10-04 18:54                 ` Andrew Morton
2007-10-05 12:30             ` Fengguang Wu
2007-10-05 12:30               ` Fengguang Wu
2007-10-05 12:30                 ` Fengguang Wu
2007-10-05 17:20                 ` Andrew Morton
2007-10-05 17:20                   ` Andrew Morton
2007-10-06  2:32                   ` Fengguang Wu
2007-10-06  2:32                     ` Fengguang Wu
2007-10-06  2:32                       ` Fengguang Wu
2007-10-07 23:54               ` David Chinner
2007-10-07 23:54                 ` David Chinner
2007-10-08  0:33                 ` Fengguang Wu
2007-10-08  0:33                   ` Fengguang Wu
2007-10-08  0:33                     ` Fengguang Wu
2007-10-04 21:07           ` Miklos Szeredi
2007-10-04 21:07             ` Miklos Szeredi
2007-10-04 21:56 ` Andrew Morton
2007-10-04 21:56   ` Andrew Morton
2007-10-04 22:39   ` Miklos Szeredi
2007-10-04 22:39     ` Miklos Szeredi
2007-10-04 23:09     ` Andrew Morton
2007-10-04 23:09       ` Andrew Morton
2007-10-04 23:26       ` Miklos Szeredi
2007-10-04 23:26         ` Miklos Szeredi
2007-10-04 23:48         ` Andrew Morton
2007-10-04 23:48           ` Andrew Morton
2007-10-05  0:12           ` Miklos Szeredi
2007-10-05  0:12             ` Miklos Szeredi
2007-10-05  0:48             ` Andrew Morton
2007-10-05  0:48               ` Andrew Morton
2007-10-05  8:22               ` Peter Zijlstra
2007-10-05  9:22                 ` Miklos Szeredi
2007-10-05  9:22                   ` Miklos Szeredi
2007-10-05  9:47                   ` Peter Zijlstra
2007-10-05 10:27                     ` Miklos Szeredi
2007-10-05 10:27                       ` Miklos Szeredi
2007-10-05 10:32                       ` Miklos Szeredi
2007-10-05 10:32                         ` Miklos Szeredi
2007-10-05 15:43                         ` John Stoffel
2007-10-05 15:43                           ` John Stoffel
2007-10-05 10:57                       ` Peter Zijlstra
2007-10-05 11:27                         ` Miklos Szeredi
2007-10-05 11:27                           ` Miklos Szeredi
2007-10-05 17:50                         ` Trond Myklebust
2007-10-05 17:50                           ` Trond Myklebust
2007-10-05 18:32                           ` Peter Zijlstra
2007-10-05 18:32                             ` Peter Zijlstra
2007-10-05 19:20                             ` Trond Myklebust
2007-10-05 19:20                               ` Trond Myklebust
2007-10-05 19:23                               ` Trond Myklebust
2007-10-05 19:23                                 ` Trond Myklebust
2007-10-05 21:07                                 ` Peter Zijlstra
2007-10-05 21:07                                   ` Peter Zijlstra
2007-10-06  0:40                             ` Fengguang Wu
2007-10-06  0:40                               ` Fengguang Wu
2007-10-06  0:40                                 ` Fengguang Wu
2007-10-05  7:32       ` Peter Zijlstra
2007-10-05 19:54         ` Rik van Riel
2007-10-05 19:54           ` Rik van Riel

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=1191504186.22357.20.camel@twins \
    --to=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=miklos@szeredi.hu \
    --cc=wfg@mail.ustc.edu.cn \
    /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.