Re: 2.6.12-rc2 + rc3: reaim with ext3 - system stalls.

From: Badari Pulavarty
Date: Fri May 06 2005 - 10:23:25 EST


On Fri, 2005-05-06 at 03:14, Jan Kara wrote:
> Hello Badari!
>
> > I have an extremely simple patch to fix the problem.
> > Basically, move the journal_start_handle from writepages()
> > to ext3_writepages_get_block() (which gets called after locking
> > the page). What am I missing here ? The patch can't
> > be that simple :(
> Umm. I think this change does not help much - you solve the problem
> for the first page but then you unlock that page and you'd like to lock
> the next one and you're again in trouble (trying to acquire PageLock
> wile holding transaction open).
> I can see three solutions of the problem:
> Either do ext3_journal_start/stop for each page - you should be actually
> getting the handle of the same transaction until the transaction gets
> filled. But still you'll have some overhead of the calls in JBD. I
> actually don't see much difference to the approach we used before your
> patch but probably there's some.

I will patch it and find out if it buys anything. I am not hopeful
either.

> Or rewrite __mpage_writepages() to lock a page range (e.g. lock pages
> until we find some on which we'd block) and then call some filesystem
> routine to write-out all the locked pages (which would start a
> transaction and so on). But this is more work.

We are re-writing mpage_writepages() anyway for supporting delayed
and multiblock allocation. So I will talk to Suparna and see if we
can do this also. But this requires more calls to figure out, if we
need block allocation and then start the transaction. (getblock(READ)
followed by getblock(WRITE) after starting transaction). Isn't it ?

> Finally there's the theoretical ;) possibility to rewrite all the
> write-out code and change the lock ordering to journal->PageLock...
>

Its beyond my capabilities :(

Thanks,
Badari

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/