From: Austin Gonyou <austin@digitalroadkill.net>
To: Lukas Hejtmanek <xhejtman@mail.muni.cz>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Terrible VM in 2.4.11+?
Date: 08 Jul 2002 17:37:02 -0500 [thread overview]
Message-ID: <1026167822.16937.5.camel@UberGeek> (raw)
In-Reply-To: <20020709001137.A1745@mail.muni.cz>
I do things like this regularly, and have been using kernels 2.4.10+ on
many types of boxen, but have yet to see this behavior. I've done this
same type of test with 16k blocks up to 10M, and not had this problem I
usually do test with regard to I/O on SCSI, but have tested on IDE,
since we use many IDE systems for developers. I found though, that using
something like LVM, and overwhelming it, causes bdflush to go crazy. I
can hit the wall you refer to then.When bdflushd is too busy...it does
in fact seem to *lock* the system, but of course..it's just bdflush
doing it's thing. If I modify the bdflush params..this causes things to
work just fine, at least, useable.
On Mon, 2002-07-08 at 17:11, Lukas Hejtmanek wrote:
> Hello,
>
> as of the last stable version 2.4.18 VM management does not work for me
> properly. I have Athlon system with 512MB ram, 2.4.18 kernel without any
> additional patches.
>
> I run following sequence of commands:
>
> dd if=/dev/zero of=/tmp bs=1M count=512 &
> find / -print &
> { wait a few seconds }
> sync
>
> at this point find stops completely or at least almost stops.
>
> The same if I copy from /dev/hdf to /dev/hda. XOSVIEW shows only reading or only
> writing (as bdflushd is flushing buffers). It never shows parallel reading and
> writing. /proc/sys/* has default settings. I do not know the reason why i/o
> system stops when bdflushd is flushing buffers nor reading can be done.
>
> --
> Lukáš Hejtmánek
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Austin Gonyou <austin@digitalroadkill.net>
next prev parent reply other threads:[~2002-07-08 22:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-08 22:11 Terrible VM in 2.4.11+? Lukas Hejtmanek
2002-07-08 22:37 ` Austin Gonyou [this message]
2002-07-08 22:50 ` Lukas Hejtmanek
2002-07-08 22:58 ` J.A. Magallon
2002-07-08 23:58 ` Lukas Hejtmanek
2002-07-09 10:48 ` Terrible VM in 2.4.11+ again? Lukas Hejtmanek
2002-07-10 16:34 ` Andrea Arcangeli
[not found] ` <20020801113124.GA755@mail.muni.cz>
[not found] ` <20020801140348.GM1132@dualathlon.random>
[not found] ` <20020801141940.GB755@mail.muni.cz>
2002-08-01 15:39 ` Terrible VM in 2.4.19rc3aa4 once again? Andrea Arcangeli
[not found] ` <20020801220143.GC755@mail.muni.cz>
2002-08-01 22:14 ` Andrea Arcangeli
2002-07-10 8:43 ` Terrible VM in 2.4.11+? Thomas Tonino
2002-07-10 8:49 ` Jens Axboe
2002-07-10 13:52 ` Thomas Tonino
2002-07-10 16:41 ` Andrea Arcangeli
2002-07-10 12:34 ` Adrian Bunk
2002-07-08 23:04 ` Austin Gonyou
2002-07-08 23:27 ` khromy
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=1026167822.16937.5.camel@UberGeek \
--to=austin@digitalroadkill.net \
--cc=linux-kernel@vger.kernel.org \
--cc=xhejtman@mail.muni.cz \
/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.