From: Andrew Morton <akpm@osdl.org>
To: Suleiman Souhlal <ssouhlal@FreeBSD.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: linux-kernel@vger.kernel.org, balbir@in.ibm.com,
csturtiv@sgi.com, daw@sgi.com, guillaume.thouvenin@bull.net,
jlan@sgi.com, nagar@watson.ibm.com, tee@sgi.com
Subject: Re: [patch 03/13] io-accounting: write accounting
Date: Wed, 13 Dec 2006 00:59:54 -0800 [thread overview]
Message-ID: <20061213005954.e2d32446.akpm@osdl.org> (raw)
In-Reply-To: <457FBDBE.10102@FreeBSD.org>
On Wed, 13 Dec 2006 00:45:50 -0800
Suleiman Souhlal <ssouhlal@FreeBSD.org> wrote:
> akpm@osdl.org wrote:
> > From: Andrew Morton <akpm@osdl.org>
> >
> > Accounting writes is fairly simple: whenever a process flips a page from clean
> > to dirty, we accuse it of having caused a write to underlying storage of
> > PAGE_CACHE_SIZE bytes.
>
> On architectures where dirtying a page doesn't cause a page fault (like i386), couldn't you end up billing the wrong process (in fact, I think that even on other archituctures set_page_dirty() doesn't get called immediately in the page fault handler)?
Yes, that would be a problem in 2.6.18 and earlier.
In 2.6.19 and later, we do take a fault when transitioning a page from
pte-clean to pte-dirty. That was done to get the dirty-page accounting
right - to avoid the all-of-memory-is-dirty-but-the-kernel-doesn't-know-it
problem.
> AFAICS, set_page_dirty() is mostly called when trying to unmap a page when trying to shrink LRU lists, and there is no guarantee that this happens under the process that dirtied it (in fact, the set_page_dirty() is often done by kswapd).
hm, that code is still there in zap_pte_range(). If all is well, that
set_page_dirty() call should never return true. Peter did, you ever test
for that?
(Well, it might return true in rare races, because zap_pte_range() doesn't
lock the pages)
next prev parent reply other threads:[~2006-12-13 9:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-08 11:52 [patch 03/13] io-accounting: write accounting akpm
2006-12-13 8:45 ` Suleiman Souhlal
2006-12-13 8:59 ` Andrew Morton [this message]
2006-12-13 10:04 ` Peter Zijlstra
2006-12-13 10:35 ` Suleiman Souhlal
2006-12-13 11:02 ` Suleiman Souhlal
2006-12-13 19:07 ` Andrew Morton
2006-12-13 22:00 ` Andrew Morton
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=20061213005954.e2d32446.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=a.p.zijlstra@chello.nl \
--cc=balbir@in.ibm.com \
--cc=csturtiv@sgi.com \
--cc=daw@sgi.com \
--cc=guillaume.thouvenin@bull.net \
--cc=jlan@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nagar@watson.ibm.com \
--cc=ssouhlal@FreeBSD.org \
--cc=tee@sgi.com \
/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.