Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 236088 - GFS2 async locking has sync callback which reads inode block
Summary: GFS2 async locking has sync callback which reads inode block
Alias: None
Product: Fedora
Classification: Fedora
Component: GFS-kernel
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Steve Whitehouse
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-04-11 21:31 UTC by Steve Whitehouse
Modified: 2008-06-03 11:05 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2008-06-03 11:05:44 UTC

Attachments (Terms of Use)

Description Steve Whitehouse 2007-04-11 21:31:41 UTC
When GFS2's async lock completes on an inode, it reads the inode block. This
makes it rather slow:

In the lock_nolock case the read is done (sync) in the context of the lock
requesting function making it rather slow.

In the lock_dlm case, the read is done in the dlm's callback context (i.e. one
of the two threads in lock_dlm) and this blocks further lock callbacks.

By making the reads async, there is a good chance that they'll be merged, thus
resulting in more efficient I/O. In addition other lock completions will not be
blocked up against this I/O.

Comment 1 Steve Whitehouse 2007-04-12 15:00:41 UTC
The way to fix this one is to add a set of list heads (possibly duplicated per
cpu to avoid locking problems) one of which is the "immediate" queue and the
others of which represent some delayed action. This is the classic way to
implement timers for example.

The idea is that we have a daemon which will run the immediate queue whenever it
has any entries on it and that the daemon will wake periodically to move the
other entries in the delayed lists up the queue.

This can take care of a number of other tasks too:

 - reclaim (can make this delayed now - v. useful)
 - a replacement for the scanning that we do for expired locks
 - plus the async disk I/O required for this bug (need to make lists irq proof)

Comment 2 Steve Whitehouse 2008-06-03 11:05:44 UTC
The latest glock patch has fixed this upstream.

Note You need to log in before you can comment on or make changes to this bug.