From: Suleiman Souhlal <ssouhlal@FreeBSD.org>
To: Suleiman Souhlal <ssouhlal@FreeBSD.org>
Cc: Andrew Morton <akpm@osdl.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
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 03:02:38 -0800 [thread overview]
Message-ID: <457FDDCE.7010303@FreeBSD.org> (raw)
In-Reply-To: <457FD777.9040703@FreeBSD.org>
Suleiman Souhlal wrote:
> Andrew Morton wrote:
>
>> 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.
>
>
> Ah yes indeed. I'm unable to keep up with all the new developments. :-(
>
> However, if my understanding of this code is correct, it seems that the
> page fault is only done for shared writable VMAs, so you still can't
> rely on set_page_dirty() always being called by the process that
> dirtied the page in the first place.
>
> Am I wrong?
Yes I am.
The only I/O non-shared VMAs might cause is from swapping, and I'm not
sure if the io accounting patches actually care about that.
My confusion came from the term "shared": A VMA is considered shared
whenever MAP_SHARED is specified, even if it only has only one single
"user".
-- Suleiman
next prev parent reply other threads:[~2006-12-13 11:03 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
2006-12-13 10:04 ` Peter Zijlstra
2006-12-13 10:35 ` Suleiman Souhlal
2006-12-13 11:02 ` Suleiman Souhlal [this message]
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=457FDDCE.7010303@FreeBSD.org \
--to=ssouhlal@freebsd.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@osdl.org \
--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=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.