mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Suleiman Souhlal <ssouhlal@FreeBSD.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 14:00:58 -0800	[thread overview]
Message-ID: <20061213140058.be5f7445.akpm@osdl.org> (raw)
In-Reply-To: <20061213110701.37300a1e.akpm@osdl.org>

On Wed, 13 Dec 2006 11:07:01 -0800
Andrew Morton <akpm@osdl.org> wrote:

> On Wed, 13 Dec 2006 03:02:38 -0800
> Suleiman Souhlal <ssouhlal@FreeBSD.org> wrote:
> 
> > 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.
> 
> Yes, the patches do attempt to correctly account for swap IO.  swapin is
> accounted in submit_bio() and swapout is, err, not accounted at all.  Drat,
> I forgot to retest that.
> 

hey, this is hard.

The obvious "fix" is to do:

--- a/mm/page-writeback.c~a
+++ a/mm/page-writeback.c
@@ -816,8 +816,10 @@ int fastcall set_page_dirty(struct page 
 		return (*spd)(page);
 	}
 	if (!PageDirty(page)) {
-		if (!TestSetPageDirty(page))
+		if (!TestSetPageDirty(page)) {
+			task_io_account_write(PAGE_SIZE);
 			return 1;
+		}
 	}
 	return 0;
 }
_


but that means that memset(malloc(1000000)) will accuse the task of having
done 1MB of writing, which is daft.

What would be appropriate here is to account the task with the write when
someone moves a dirty anon page into swapcache.  That means that some
random task needs to locate the task which "owns" this anon page.  So in
shrink_page_list()->add_to_swap() we need to hunt down the appropriate
locks, do the rmap walk, find the vma, find the mm, then wonder how the
heck we find the right task_struct based on the mm_struct.

I think I'll back slowly away from this problem and mark it as "known
shortcoming".

Which perhaps means that we should not account for swapin either.

      reply	other threads:[~2006-12-13 22:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-08 11:52 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
2006-12-13 19:07         ` Andrew Morton
2006-12-13 22:00           ` Andrew Morton [this message]

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=20061213140058.be5f7445.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®