[lkml]   [2006]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH] set_page_buffer_dirty should skip unmapped buffers
> On Mon, 2006-09-11 at 11:46 +0200, Jan Kara wrote:
> ...
> > >
> > > I don't have any performance tests handy. We have some automated tests I
> > > can schedule to run to verify the stability aspects.
> > OK. I've run IOZONE rewrite throughput test on my computer with
> > iozone -t 10 -i 0 -s 10M -e
> > 2.6.18-rc6 and the same kernel + my patch seem to give almost the same
> > results. The strange thing was that both in vanilla and patched kernel there
> > were several runs where a write througput (when iozone was creating the file)
> > was suddenly 10% of the usual value (18MB/s vs. 2MB/s). The rewrite numbers
> > were always fine. Maybe that has something to do with block allocation
> > code. Anyway, it is not a regression of my patch so unless your test
> > finds some problem I think the patch should be ready for inclusion into
> > -mm...
> Your patch seems to be working fine. I haven't found any major
> regression yet.
> I spent lot of time trying to reproduce the problem with buffer-debug
> Andrew sent out - I really wanted to get to bottom of whats really
> happening here (since your patch made it go away).
> Yes. Your theory is correct. journal_dirty_data() is moving the
> buffer-head from commited transaction to current one and
> journal_unmap_buffer() is discarding and cleaning up the buffer-head.
> Later set_page_dirty() dirties the buffer-head there by causing
> BUG() in submit_bh().
> Here is the buffer-trace-debug output to confirm it. I can sleep better
> now :) Now we can figure out, if your fix is the right one or not ..
OK, good to hear :). My patch should be prone at least to this problem
(I'm not saying it could not have introduced any other ;). It locks the
buffer and if it needed to drop JBD spin locks, it also checks whether
the buffer remained in the BJ_SyncData list. Hence if the
journal_dirty_data() steals the buffer while we are locking it we find
that out and forget about the buffer. Once the buffer is locked,
journal_dirty_data() won't touch it.
I guess the patch is good enough to send it to Andrew...


Jan Kara <>
SuSE CR Labs
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-09-11 22:55    [W:0.053 / U:2.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site