[Bug 221152] GFS2: Clean up of glock code
bugzilla at redhat.com
bugzilla at redhat.com
Mon Jun 2 09:39:38 UTC 2008
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 at redhat.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|rawhide |9
swhiteho at redhat.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|9 |rawhide
------- Additional Comments From fedora-triage-list at 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 at 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.
More information about the fedora-triage-list
mailing list