From: Jens Axboe <axboe@suse.de>
To: Josh McKinney <forming@home.com>
Cc: linux-kernel@vger.kernel.org, Priit Randla <priit.randla@eyp.ee>
Subject: Re: scheduler went mad?
Date: Thu, 12 Apr 2001 17:46:08 +0200 [thread overview]
Message-ID: <20010412174608.O498@suse.de> (raw)
In-Reply-To: <3AD46930.B6CC9565@eyp.ee> <20010411134602.A4328@home.com>
In-Reply-To: <20010411134602.A4328@home.com>; from forming@home.com on Wed, Apr 11, 2001 at 01:46:02PM -0500
On Wed, Apr 11 2001, Josh McKinney wrote:
> I had the almost exact same thing happen to me just yesterday, I started up
> xcdroast, and cdda2wav and kswapd went crazy, backed out of X and all was
> well, and still is.
>
> Same kernel as you too.
I can tell you why this happens. Earlier kernels allocated one cd frame
worth of data for cdda ripping, but it was recently bumped to allow as
many as the ripping program asks for (up to 8). This requires a 4-5 page
allocation on x86, which is of course not reliable. cdrom.c adjusts for
failed allocations and drops to fewer number of frames (8 -> 4 -> 2 and
then just 1), but apparently the vm isn't handling this too well if
kswapd is going crazy.
I can switch to a static 8 frame allocation, but IMHO the vm should be
able to handle situations like this. It's not that unusual for a driver
to ask for a bigger chunk of memory if it can go faster that way, and
then be prepared to settle for less if need be. For cdda ripping, it
really does make a difference.
However, I can change ide-cd to do scatter gather in this case. It's the
nicer thing to do anyway. Does cdda2wav have some sort of 'do X number
of frames at the time' option? If so, use 1 and there should be no
problems.
--
Jens Axboe
next prev parent reply other threads:[~2001-04-12 15:47 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-11 14:24 scheduler went mad? Priit Randla
2001-04-11 18:46 ` Josh McKinney
2001-04-12 15:46 ` Jens Axboe [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-04-12 14:57 Valdis.Kletnieks
2001-04-12 15:12 ` Alan Cox
2001-04-12 15:44 ` Valdis.Kletnieks
2001-04-12 18:31 ` Valdis.Kletnieks
2001-04-12 15:43 ` Hugh Dickins
2001-04-12 16:02 ` Alan Cox
2001-04-12 16:29 ` Rik van Riel
2001-04-12 15:08 ` Marcelo Tosatti
2001-04-12 15:10 ` Marcelo Tosatti
2001-04-12 18:18 ` Szabolcs Szakacsits
2001-04-12 17:56 ` Rik van Riel
2001-04-12 20:12 ` Szabolcs Szakacsits
2001-04-12 20:18 ` Rik van Riel
2001-04-12 23:02 ` Szabolcs Szakacsits
2001-04-12 22:24 ` Valdis.Kletnieks
2001-04-12 16:53 ` Rik van Riel
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=20010412174608.O498@suse.de \
--to=axboe@suse.de \
--cc=forming@home.com \
--cc=linux-kernel@vger.kernel.org \
--cc=priit.randla@eyp.ee \
/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