Date: Tue, 27 Dec 2011 18:05:44 +0100 From: Attilio Rao <attilio@freebsd.org> To: mdf@freebsd.org Cc: freebsd-hackers@freebsd.org, Giovanni Trematerra <giovanni.trematerra@gmail.com>, Venkatesh Srinivas <vsrinivas@dragonflybsd.org> Subject: Re: Per-mount syncer threads and fanout for pagedaemon cleaning Message-ID: <CAJ-FndBDTgHobsN9t49Ss-O56asDSyCUMogz5dZqdUhXnWxTCw@mail.gmail.com> In-Reply-To: <CAMBSHm98RoTnKihsmC0gT3GYGiobhnYgbURH%2BoyQE_Eo0q%2Bq6w@mail.gmail.com> References: <20111226202414.GA18713@centaur.acm.jhu.edu> <CACfq090S=U-_3QA1XLNX31SD2zgAcnmG9kJrXYCvhR9Q-2JfKA@mail.gmail.com> <CAJ-FndDY-40xqVBTS5wSyrw3cxbG=hTjQ=et-nBtkSnesxrgZQ@mail.gmail.com> <CAMBSHm98RoTnKihsmC0gT3GYGiobhnYgbURH%2BoyQE_Eo0q%2Bq6w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2011/12/27 <mdf@freebsd.org>: > On Tue, Dec 27, 2011 at 8:05 AM, Attilio Rao <attilio@freebsd.org> wrote: >> 2011/12/27 Giovanni Trematerra <giovanni.trematerra@gmail.com>: >>> On Mon, Dec 26, 2011 at 9:24 PM, Venkatesh Srinivas >>> <vsrinivas@dragonflybsd.org> wrote: >>>> Hi! >>>> >>>> I've been playing with two things in DragonFly that might be of intere= st >>>> here. >>>> >>>> Thing #1 :=3D >>>> >>>> First, per-mountpoint syncer threads. Currently there is a single thre= ad, >>>> 'syncer', which periodically calls fsync() on dirty vnodes from every = mount, >>>> along with calling vfs_sync() on each filesystem itself (via syncer vn= odes). >>>> >>>> My patch modifies this to create syncer threads for mounts that reques= t it. >>>> For these mounts, vnodes are synced from their mount-specific thread r= ather >>>> than the global syncer. >>>> >>>> The idea is that periodic fsync/sync operations from one filesystem sh= ould >>>> not >>>> stall or delay synchronization for other ones. >>>> The patch was fairly simple: >>>> http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/50e4012a4b55e1= efc595db0db397b4365f08b640 >>>> >>> >>> There's something WIP by attilio@ on that area. >>> you might want to take a look at >>> http://people.freebsd.org/~attilio/syncer_alpha_15.diff >>> >>> I don't know what hammerfs needs but UFS/FFS and buffer cache make a go= od >>> job performance-wise and so the authors are skeptical about the boost t= hat such >>> a change can give. We believe that brain cycles need to be spent on >>> other pieces of the system such as ARC and ZFS. >> >> More specifically, it is likely that focusing on UFS and buffer cache >> for performance is not really useful, we should drive our efforts over >> ARC and ZFS. >> Also, the real bottlenecks in our I/O paths are in GEOM >> single-threaded design, lack of unmapped I/O functionality, possibly >> lack of proritized I/O, etc. > > Indeed, Isilon (and probably other vendors as well) entirely skip > VFS_SYNC when the WAIT argument is MNT_LAZY. =C2=A0Since we're a > distributed journalled filesystem, syncing via a system thread is not > a relevant operation; i.e. all writes that have exited a VOP_WRITE or > similar operation are already in reasonably stable storage in a > journal on the relevant nodes. > > However, we do then have our own threads running on each node to flush > the journal regularly (in addition to when it fills up), and I don't > know enough about this to know if it could be fit into the syncer > thread idea or if it's too tied in somehow to our architecture. I'm not really sure how does journaling is implemented on OneFS, but when I made this patch SU+J wasn't yet there. Also, this patch just adds the infrastructure for a multithreaded and configurable syncer, which means it still requires the UFS bits for skipping the "double-syncing" (alias the MNT_LAZY skippage you mentioned). Attilio --=20 Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndBDTgHobsN9t49Ss-O56asDSyCUMogz5dZqdUhXnWxTCw>