public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: torvalds@transmeta.com (Linus Torvalds)
To: linux-kernel@vger.kernel.org
Subject: Re: [BUG] /proc/<pid>/stat access stalls badly for swapping process, 2.4.0-test10
Date: 10 Nov 2000 09:07:48 -0800	[thread overview]
Message-ID: <8uha14$3gi$1@penguin.transmeta.com> (raw)
In-Reply-To: <Pine.LNX.4.10.10011091005390.1909-100000@penguin.transmeta.com> <Pine.Linu.4.10.10011100732250.601-100000@mikeg.weiden.de>

In article <Pine.Linu.4.10.10011100732250.601-100000@mikeg.weiden.de>,
Mike Galbraith  <mikeg@wen-online.de> wrote:
>> 
>> (This schenario, btw, is much harder to trigger on SMP than on UP. And
>> it's completely separate from the issue of simple disk bandwidth issues
>> which can obviously cause no end of stalls on anything that needs the
>> disk, and which can also happen on SMP).
>
>Unfortunately, it didn't help in the scenario I'm running.
>
>time make -j30 bzImage:
>
>real    14m19.987s  (within stock variance)
>user    6m24.480s
>sys     1m12.970s

Note that the above kin of "throughput performance" should not have been
affected, and was not what I was worried about. 

>procs                      memory    swap          io     system         cpu
> r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us  sy  id
>31  2  1     12   1432   4440  12660   0  12    27   151  202   848  89  11   0
>34  4  1   1908   2584    536   5376 248 1904   602   763  785  4094  63  32  5
>13 19  1  64140  67728    604  33784 106500 84612 43625 21683 19080 52168  28  22  50

Looks like there was a big delay in vmstat there - that could easily be
due to simple disk throughput issues..

Does it feel any different under the original load that got the original
complaint? The patch may have just been buggy and ineffective, for all I
know. 

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  parent reply	other threads:[~2000-11-10 17:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.Linu.4.10.10011091452270.747-100000@mikeg.weiden.de>
2000-11-09 18:31 ` [BUG] /proc/<pid>/stat access stalls badly for swapping process, 2.4.0-test10 Linus Torvalds
2000-11-10  7:34   ` Mike Galbraith
2000-11-10 10:47     ` Mike Galbraith
2000-11-10 17:07     ` Linus Torvalds [this message]
2000-11-10 21:42   ` [BUG] /proc/<pid>/stat access stalls badly for swapping process,2.4.0-test10 David Mansfield
2000-11-11  6:20     ` Linus Torvalds
2000-11-01 18:38 [BUG] /proc/<pid>/stat access stalls badly for swapping process, 2.4.0-test10 David Mansfield
2000-11-01 18:48 ` Rik van Riel
2000-11-02  7:19   ` Mike Galbraith
2000-11-02 21:59     ` Val Henson
2000-11-03  1:37       ` Jens Axboe
2000-11-03  5:56         ` Mike Galbraith
2000-11-03 15:45           ` Mike Galbraith
2000-11-03 19:38             ` Jens Axboe
2000-11-04  5:43               ` Mike Galbraith
2000-11-02  8:40   ` Christoph Rohland

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='8uha14$3gi$1@penguin.transmeta.com' \
    --to=torvalds@transmeta.com \
    --cc=linux-kernel@vger.kernel.org \
    /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