From: Andrew Morton <akpm@osdl.org>
To: Takashi Iwai <tiwai@suse.de>
Cc: andrea@suse.de, mjy@geizhals.at, linux-kernel@vger.kernel.org
Subject: Re: CONFIG_PREEMPT and server workloads
Date: Thu, 18 Mar 2004 14:32:05 -0800 [thread overview]
Message-ID: <20040318143205.6a9c4e89.akpm@osdl.org> (raw)
In-Reply-To: <s5hlllycgz3.wl@alsa2.suse.de>
Takashi Iwai <tiwai@suse.de> wrote:
>
> --- linux-2.6.4-8/fs/jbd/commit.c-dist 2004-03-16 23:00:40.000000000 +0100
> +++ linux-2.6.4-8/fs/jbd/commit.c 2004-03-18 02:42:41.043448624 +0100
> @@ -290,6 +290,9 @@ write_out_data_locked:
> commit_transaction->t_sync_datalist = jh;
> break;
> }
> +
> + if (need_resched())
> + break;
> } while (jh != last_jh);
>
> if (bufs || need_resched()) {
Yup, this has problems.
What we're doing here is walking (under spinlock) a ring of buffers
searching for unlocked dirty ones to write out.
Suppose the ring has thousands of locked buffers and there is a RT task
scheduling at 1kHz. Each time need_resched() comes true we break out of
the search, schedule away and then restart the search from the beginning.
So if the time to walk that ring of buffers exceeds one millisecond the
kernel will make no progress. Eventually things will fix themselves up as
the I/O completes against those buffers but in the meanwhile we chew 100%
of CPU.
A few lines higher up we advance the searching start point so the next
search will start at the current position. But that's when it is known
that we made some forward progress. In the above patch we are vulnerable
to the situation where _all_ of the buffers on that ring are locked.
The below might suit, although I haven't tested it. It needs careful
testing too - it will impact I/O scheduling efficiency.
--- 25/fs/jbd/commit.c~a Thu Mar 18 14:23:40 2004
+++ 25-akpm/fs/jbd/commit.c Thu Mar 18 14:28:46 2004
@@ -280,6 +280,22 @@ write_out_data_locked:
goto write_out_data;
}
}
+ } else if (need_resched()) {
+ /*
+ * A locked buffer, and we're being a CPU pig. We
+ * cannot just schedule away because it may be the case
+ * that *all* the buffers are locked. So let's just
+ * wait until this buffer has been written.
+ *
+ * If we already have some buffers in wbuf[] then fine,
+ * we're making forward progress.
+ */
+ if (bufs)
+ break;
+ commit_transaction->t_sync_datalist = jh;
+ spin_unlock(&journal->j_list_lock);
+ wait_on_buffer(bh);
+ goto write_out_data;
}
if (bufs == ARRAY_SIZE(wbuf)) {
/*
_
next prev parent reply other threads:[~2004-03-18 22:30 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-18 4:00 Marinos J. Yannikos
2004-03-18 5:12 ` Andrew Morton
2004-03-18 6:03 ` Andrea Arcangeli
2004-03-18 9:50 ` Andrew Morton
2004-03-18 14:51 ` Andrea Arcangeli
2004-03-18 15:34 ` Robert Love
2004-03-18 16:01 ` Andrea Arcangeli
2004-03-18 17:39 ` Andrew Morton
2004-03-18 17:58 ` Andrea Arcangeli
2004-03-18 18:26 ` Andrew Morton
2004-03-18 18:38 ` Andrea Arcangeli
2004-03-18 18:47 ` Andrew Morton
2004-03-18 19:01 ` Andrea Arcangeli
2004-03-18 17:48 ` Robert Love
2004-03-18 18:00 ` Andrea Arcangeli
2004-03-20 10:48 ` Jamie Lokier
2004-03-19 2:17 ` Nick Piggin
[not found] ` <20040319050948.GN2045@holomorphy.com>
2004-03-20 12:14 ` Andrea Arcangeli
2004-03-20 14:51 ` William Lee Irwin III
2004-03-20 15:03 ` Andrea Arcangeli
2004-03-20 15:09 ` William Lee Irwin III
2004-03-24 13:57 ` Takashi Iwai
2004-03-24 14:52 ` Andrea Arcangeli
2004-03-24 15:11 ` William Lee Irwin III
2004-03-18 15:20 ` Tom Sightler
2004-03-18 15:37 ` Andrea Arcangeli
2004-03-18 23:54 ` Tom Sightler
2004-03-18 15:39 ` Robert Love
2004-03-18 15:28 ` Takashi Iwai
2004-03-18 15:40 ` Robert Love
2004-03-18 15:42 ` Andrea Arcangeli
2004-03-18 19:01 ` Andrew Morton
2004-03-18 19:08 ` Takashi Iwai
2004-03-18 19:18 ` Andrew Morton
2004-03-18 19:20 ` Takashi Iwai
2004-03-18 19:43 ` Andrea Arcangeli
2004-03-18 19:50 ` Takashi Iwai
2004-03-18 19:24 ` Robert Love
2004-03-19 22:03 ` Valdis.Kletnieks
2004-03-19 22:12 ` Robert Love
2004-03-24 15:00 ` Takashi Iwai
2004-03-18 19:16 ` Takashi Iwai
2004-03-18 19:29 ` Andrew Morton
2004-03-18 19:48 ` Chris Mason
2004-03-19 11:37 ` Takashi Iwai
2004-03-19 13:46 ` Chris Mason
2004-03-19 14:06 ` Takashi Iwai
[not found] ` <20040318221006.74246648.akpm@osdl.org>
2004-03-19 10:30 ` Takashi Iwai
2004-03-23 9:14 ` Dipankar Sarma
2004-03-19 17:22 ` Dipankar Sarma
2004-03-19 18:03 ` Andrew Morton
2004-03-20 12:24 ` Andrea Arcangeli
2004-03-20 13:13 ` Dipankar Sarma
2004-03-18 19:39 ` Andrea Arcangeli
2004-03-18 22:32 ` Andrew Morton [this message]
2004-03-18 22:54 ` Chris Mason
2004-03-18 23:57 ` Andrew Morton
2004-03-19 20:46 ` Takashi Iwai
2004-03-19 21:08 ` Andrew Morton
2004-03-19 3:07 ` Eric St-Laurent
2004-03-19 11:23 ` Takashi Iwai
2004-03-19 13:35 ` Chris Mason
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=20040318143205.6a9c4e89.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mjy@geizhals.at \
--cc=tiwai@suse.de \
/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
Powered by JetHome