[Bug 221152] GFS2: Clean up of glock code

[Red Hat Bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: GFS2: Clean up of glock code


https://bugzilla.redhat.com/show_bug.cgi?id=221152


fedora-triage-list(a)redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|rawhide                     |9

swhiteho(a)redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|9                           |rawhide




------- Additional Comments From fedora-triage-list(a)redhat.com  2008-05-13 22:32 EST
-------
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

------- Additional Comments From swhiteho(a)redhat.com  2008-06-02 05:39 EST -------
With the latest upstream code, a lot of the originally proposed changes are
done. Here is a list of what is left:

 1. Documentation - how does it work? :-)
 2. Remove one (or both?!) of ->go_xmote_bh and ->go_lock. The latter is more
important since it sits in the fast path.
 3. Remove ->go_unlock if possible
 4. lockdep support (task #7 from the above list)
 5. The GL_NOCACHE flag could be replaced by a call to ->go_demote_ok
 6. The GL_ASYNC flag could be replaced by a "wait" flag to gfs_glock_nq
 7. The GLF_STICKY flag coule be replaced by a call to ->go_demote_ok
 8. Remove gfs2_glockd and replace with the workqueue
 9. Remove gfs2_scand and replace with the workqueue
 10. Investigate why the workqueue seems to be the cause of poor performance wrt
lock completions and consider whether its possible to have a per-glock tasklet
instead. This issue here is whether we can submit I/O from that context or not.
If we were able to eliminate all I/O from the glops callbacks, then that would
cease to be a problem, but I'm not sure thats very practical.
 11. Make the I/O async wrt the workqueue to avoid blocking I/O requests by
waiting for other I/O requests. Has implications for task #10



-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.