On Wed, May 20 2009, Jan Kara wrote:
> On Wed 20-05-09 13:32:34, Jens Axboe wrote:
> > On Wed, May 20 2009, Jan Kara wrote:
> > > Hi Jens,
> > >
> > > a few comments here. Mainly, I still don't think the sys_sync() is
> > > working right - see comments below.
> >
> > Thanks! I took the liberty of killing some of the code in between, to
> > make it easier to see.
> >
> > > > +void bdi_writeback_all(struct super_block *sb, long nr_pages)
> > > > +{
> > > > + struct backing_dev_info *bdi;
> > > > +
> > > > + rcu_read_lock();
> > > > +
> > > > +restart:
> > > > + list_for_each_entry_rcu(bdi, &bdi_list, bdi_list) {
> > > Isn't the RCU list here a bit overengineering? AFAICS we use the list
> > > only here and if I'm grepping right, generic_sync_sb_inodes() is currently
> > > only used for data integrity sync (after your patches) from fs-writeback.c
> > > and by UBIFS to do equivalent of writeback_inodes(). So simple spinlock
> > > guarding the list should be just fine. Or am I missing something?
> >
> > Sure, we could. But it's really not that much of a difference,
> > implementation wise.
> Yeah. It's just that when I see RCU, I'm a bit cautious what's going on.
> When I see spinlock, everything is simple and clear ;). And I'm in favor of
> using the simplest synchronization primitive that does it's work good
> enough ;).
It's a fine rule, I agree ;-)
I'll take another look at this when splitting the sync paths.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
