lkml.org 
[lkml]   [2009]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 02/11] writeback: switch to per-bdi threads for flushing data
    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



    \
     
     \ /
      Last update: 2009-05-20 14:19    [from the cache]
    ©2003-2014 Jasper Spaans. Advertise on this site