From: Linus Torvalds <torvalds@transmeta.com>
To: Zlatko Calusic <zlatko.calusic@iskon.hr>
Cc: Marcelo Tosatti <marcelo@conectiva.com.br>,
linux-mm@kvack.org, lkml <linux-kernel@vger.kernel.org>
Subject: Re: xmm2 - monitor Linux MM active/inactive lists graphically
Date: Wed, 24 Oct 2001 21:57:18 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.33.0110242140350.9147-100000@penguin.transmeta.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0110242117150.9147-100000@penguin.transmeta.com>
On Wed, 24 Oct 2001, Linus Torvalds wrote:
>
> On 25 Oct 2001, Zlatko Calusic wrote:
> >
> > Sure. Output of 'vmstat 1' follows:
> >
> > 1 0 0 0 254552 5120 183476 0 0 12 24 178 438 2 37 60
> > 0 1 0 0 137296 5232 297760 0 0 4 5284 195 440 3 43 54
> > 1 0 0 0 126520 5244 308260 0 0 0 10588 215 230 0 3 96
> > 0 2 0 0 117488 5252 317064 0 0 0 8796 176 139 1 3 96
> > 0 2 0 0 107556 5264 326744 0 0 0 9704 174 78 0 3 97
>
> This does not look like a VM issue at all - at this point you're already
> getting only 10MB/s, yet the VM isn't even involved (there's definitely no
> VM pressure here).
I wonder if you're getting screwed by bdflush().. You do have a lot of
context switching going on, and you do have a clear pattern: once the
write-out gets going, you're filling new cached pages at about the same
pace that you're writing them out, which definitely means that the dirty
buffer balancing is nice and active.
So the problem is that you're obviously not actually getting the
throughput you should - it's not the VM, as the page cache grows nicely at
the same rate you're writing.
Try something for me: in fs/buffer.c make "balance_dirty_state()" never
return > 0, ie make the "return 1" be a "return 0" instead.
That will cause us to not wake up bdflush at all, and if you're just on
the "border" of 40% dirty buffer usage you'll have bdflush work in
lock-step with you, alternately writing out buffers and waiting for them.
Quite frankly, just the act of doing the "write_some_buffers()" in
balance_dirty() should cause us to block much better than the synchronous
waiting anyway, because then we will block when the request queue fills
up, not at random points.
Even so, considering that you have such a steady 9-10MB/s, please double-
check that it's not something even simpler and embarrassing, like just
having forgotten to enable auto-DMA in the kernel config ;)
Linus
--
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/
next prev parent reply other threads:[~2001-10-25 4:57 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-24 10:42 Zlatko Calusic
2001-10-24 14:26 ` Marcelo Tosatti
2001-10-25 0:25 ` Zlatko Calusic
2001-10-25 4:19 ` Linus Torvalds
2001-10-25 4:57 ` Linus Torvalds [this message]
2001-10-25 12:48 ` Zlatko Calusic
2001-10-25 16:31 ` Linus Torvalds
2001-10-25 17:33 ` Jens Axboe
2001-10-26 9:45 ` Zlatko Calusic
2001-10-26 10:08 ` Zlatko Calusic
2001-10-26 14:39 ` Jens Axboe
2001-10-26 14:57 ` Zlatko Calusic
2001-10-26 15:01 ` Jens Axboe
2001-10-26 16:04 ` Linus Torvalds
2001-10-26 16:57 ` Linus Torvalds
2001-10-26 17:19 ` Linus Torvalds
2001-10-28 17:30 ` Zlatko Calusic
2001-10-28 17:34 ` Linus Torvalds
2001-10-28 17:48 ` Alan Cox
2001-10-28 17:59 ` Linus Torvalds
2001-10-28 18:22 ` Alan Cox
2001-10-28 18:46 ` Linus Torvalds
2001-10-28 19:29 ` Alan Cox
2001-10-28 18:56 ` Andrew Morton
2001-10-30 8:56 ` Jens Axboe
2001-10-30 9:26 ` Zlatko Calusic
2001-10-28 19:13 ` Barry K. Nathan
2001-10-28 21:42 ` Jonathan Morton
2001-11-02 5:52 ` Zlatko's I/O slowdown status Andrea Arcangeli
2001-11-02 20:14 ` Zlatko Calusic
2001-11-02 20:26 ` Rik van Riel
2001-11-02 21:22 ` Zlatko Calusic
2001-11-02 20:57 ` Andrea Arcangeli
2001-11-02 23:23 ` Simon Kirby
2001-10-27 13:14 ` xmm2 - monitor Linux MM active/inactive lists graphically Giuliano Pochini
2001-10-28 5:05 ` Mike Fedyk
2001-10-25 9:07 ` Zlatko Calusic
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=Pine.LNX.4.33.0110242140350.9147-100000@penguin.transmeta.com \
--to=torvalds@transmeta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=marcelo@conectiva.com.br \
--cc=zlatko.calusic@iskon.hr \
/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