From: Miklos Szeredi <miklos@szeredi.hu>
To: a.p.zijlstra@chello.nl
Cc: miklos@szeredi.hu, 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:49:38 +0200 [thread overview]
Message-ID: <E1IdR58-0002Fq-00@dorka.pomaz.szeredi.hu> (raw)
In-Reply-To: <1191504186.22357.20.camel@twins> (message from Peter Zijlstra on Thu, 04 Oct 2007 15:23:06 +0200)
> > > 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.
Yeah, I guess the point of the function was to limit nr_write to
_anything_ smaller than the total memory.
> > > 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.
I guess you will have some request queue with limited length, no?
The main problem seems to be if devices use up all the reserved memory
for queuing write requests. Limiting the in-flight pages is a very
crude way to solve this, the assumptions are:
O: overhead as a fraction of the request size
T: total memory
R: reserved memory
T-R: may be full of anon pages
so if (T-R)*O > R we are in trouble.
if we limit the writeback memory to L and L*O < R we are OK. But we
don't know O (it's device dependent). We can make an estimate
calculate L based on that, but that will be a number totally
independent of the dirty threshold.
> > > 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.
For per-bdi limits we have the queue length.
Miklod
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-10-04 13:49 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
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:23 ` Peter Zijlstra
2007-10-04 13:49 ` Miklos Szeredi [this message]
2007-10-04 16:47 ` Peter Zijlstra
2007-10-04 17:46 ` Andrew Morton
2007-10-04 18:10 ` Peter Zijlstra
2007-10-04 18:54 ` Andrew Morton
[not found] ` <20071005123028.GA10372@mail.ustc.edu.cn>
2007-10-05 12:30 ` Fengguang Wu
2007-10-05 17:20 ` Andrew Morton
[not found] ` <20071006023224.GA7526@mail.ustc.edu.cn>
2007-10-06 2:32 ` Fengguang Wu
2007-10-07 23:54 ` David Chinner
[not found] ` <20071008003349.GA5455@mail.ustc.edu.cn>
2007-10-08 0:33 ` Fengguang Wu
2007-10-04 21:07 ` Miklos Szeredi
2007-10-04 21:56 ` Andrew Morton
2007-10-04 22:39 ` Miklos Szeredi
2007-10-04 23:09 ` Andrew Morton
2007-10-04 23:26 ` Miklos Szeredi
2007-10-04 23:48 ` Andrew Morton
2007-10-05 0:12 ` Miklos Szeredi
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:47 ` Peter Zijlstra
2007-10-05 10:27 ` Miklos Szeredi
2007-10-05 10:32 ` Miklos Szeredi
2007-10-05 15:43 ` John Stoffel
2007-10-05 10:57 ` Peter Zijlstra
2007-10-05 11:27 ` Miklos Szeredi
2007-10-05 17:50 ` Trond Myklebust
2007-10-05 18:32 ` Peter Zijlstra
2007-10-05 19:20 ` Trond Myklebust
2007-10-05 19:23 ` Trond Myklebust
2007-10-05 21:07 ` Peter Zijlstra
[not found] ` <20071006004028.GA7121@mail.ustc.edu.cn>
2007-10-06 0:40 ` Fengguang Wu
2007-10-05 7:32 ` Peter Zijlstra
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=E1IdR58-0002Fq-00@dorka.pomaz.szeredi.hu \
--to=miklos@szeredi.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox