linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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/

  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