From: Andrew Morton <akpm@digeo.com>
To: Joe Korty <joe.korty@ccur.com>
Cc: sct@redhat.com, adilger@clusterfs.com, rusty@rustcorp.com.au,
riel@conectiva.com.br, linux-kernel@vger.kernel.org, hch@sgi.com
Subject: Re: 2.4.21-pre2 stalls out when running unixbench
Date: Sat, 04 Jan 2003 03:11:45 -0800 [thread overview]
Message-ID: <3E16C171.BFEA45AE@digeo.com> (raw)
In-Reply-To: 200301040111.BAA00401@rudolph.ccur.com
Joe Korty wrote:
>
> > In the previous episode of "travails of a geriatric kernel jock",
> > Andrew Morton wrote:
> > >
> > > Unpatched 2.4.20 does the same thing.
> > >
> >
> > No it doesn't.
> >
> > Good news is that 2.4.20 plus recent ext3 fixes doesn't lock up
> > either.
>
> Hi Andrew,
> I have continued to play with the problem, and have gathered more evidence.
>
> Everything works (kinda) when I back out the attached 2.4.20-pre1
> patches. I am not sure how to uniquely identify patches in the BK
> tree, so I have enclosed the full text of each at the end of this
> letter.
>
> A remaining problem are long stallouts not present in 2.4.20. The
> stallouts are of uniform duration, 20 seconds, triggered aperiodically.
This is because of differences in how sync() is handled between 2.4.20's
ext3 and 2.4.21-pre2's.
2.4.20:
sync() will _start_ a commit, but will not wait on it. This was done
to fix a throughput problem with kupdate periodic writeback, which
used to use the same code as sync.
Not waiting on the writeout is OK by the letter of the POSIX spec,
but is not traditional Linux behaviour, and is undesirable IMO.
2.4.21-pre2:
sync() will start the commit, and will wait on it. So you know that
when it returns, everything which was dirty is now tight on disk.
So yes, running a looping sync while someone else is writing stuff
will take much longer in 2.4.21-pre2, because that kernel actually
waits on the writeout.
With respect to the lockup problem: it is due to a non-atomic __set_bit()
in the new buffer_attached() implementation.
Sure, we don't need atomic semantics for the BH_Attached bit because
it is always read and modified under a global spinlock. But *other*
users of buffer_head.b_state do not run under that lock so the nonatomic
RMW will stomp on their changes. 2.4.20 does not have this bug.
Here is a patch:
--- 24/include/linux/fs.h~buffer_attached-fix Sat Jan 4 03:09:13 2003
+++ 24-akpm/include/linux/fs.h Sat Jan 4 03:09:16 2003
@@ -1202,7 +1202,7 @@ static inline void mark_buffer_async(str
static inline void set_buffer_attached(struct buffer_head *bh)
{
- __set_bit(BH_Attached, &bh->b_state);
+ set_bit(BH_Attached, &bh->b_state);
}
static inline void clear_buffer_attached(struct buffer_head *bh)
_
next prev parent reply other threads:[~2003-01-04 11:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-03 16:56 2.4.21-pre2 stalls out when running unixbench Joe Korty
2003-01-03 20:07 ` Andrew Morton
2003-01-03 20:30 ` Andrew Morton
2003-01-04 1:11 ` Joe Korty
2003-01-04 11:11 ` Andrew Morton [this message]
2003-01-05 2:58 ` Joe Korty
2003-01-06 12:10 ` Stephen C. Tweedie
2003-01-06 12:15 ` John Bradford
2003-01-06 13:20 ` Stephen C. Tweedie
2003-01-06 12:16 ` Andrew Morton
2003-01-06 13:23 ` Stephen C. Tweedie
2003-01-11 8:10 ` Christoph Hellwig
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=3E16C171.BFEA45AE@digeo.com \
--to=akpm@digeo.com \
--cc=adilger@clusterfs.com \
--cc=hch@sgi.com \
--cc=joe.korty@ccur.com \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@conectiva.com.br \
--cc=rusty@rustcorp.com.au \
--cc=sct@redhat.com \
/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