From: Rick L. <ne...@se...> - 2001-05-15 18:29:02
|
I've produced the first draft of a document which can begin to describe the locks in use in the Linux kernel, and I encourage the LSE community to review it and send me comments. I've asked the maintainers of the project to place it in a public location there so it can be easily viewed. Although it's in plain text right now, it's over 1900 lines long or I'd just include it in this message.) The philosophy of why I feel this document is necessary is explained in the first few paragraphs of the document itself, so I won't repeat it here. The document itself is more of a reference document than a paper, but that's intentional for the first draft. Once we establish the "correct" use of the various locks in use in the system, we can then spend time discussing incorrect or unnecessary usages. Before we agree on "correct" usage, such discussions can become quite philosophical. The goal of the review process, though, is to insure accuracy while minimizing the impact to any one developer. Many of you who have volunteered have other irons in the fire, and I want to use your time efficiently. So I emphasize that I'm not asking any one person to review the entire document -- please review those locks that you believe you understand already and verify that I've interpreted them correctly. Note that the r/w locks are only half finished; although I believe there's only a few more hours work there, I really wanted to get this out NOW and avoid putting it off while working on "just one more thing." The remaining uses of the Big Kernel Lock are especially enigmatic. If anyone feels qualified to comment on any remaining, legitimate uses for the BKL, please do elaborate. My default belief, right now, is that all the current uses are either incorrect, unnecessary, or due to be so very soon (although I've not inserted this opinion into the document quite so succinctly.) One more topic I encourage you to comment on is support. My original intention was that this become a document submitted for inclusion in usr/src/Documentation, and that it then be maintained on an ongoing basis either by myself or another. (Yes I volunteer, initially.) If you have thoughts on format, enhancements, or support issues please do include that in your comments. Simply to provide a starting point, I'll take the position right now that it be updated no more frequently than quarterly and quite possibly less frequently. Updates will necessarily follow any new release by a minimum of six weeks since I can't make the document correct for any particular release until it is out and I have time to go through it (or unless the release waits for me and I'm quite happy to have Linux be the final gate on release thank you.) If you have other thoughts or desires on support, by all means -- dissuade me. I'm fairly open on this. Please send comments to ne...@se.... If that address causes you problems for some reason, please try ne...@us.... That address cannot reliably accept diffs currently due to possible message reformatting, so a third address you may try if you need that capability is ri...@ea.... Thank you in advance for your efforts. I encourage you to return comments by 6/1 but will accept them both sooner and later. Rick Lindsley IBM Linux Technology Center ne...@se... ne...@us... ri...@ea... |
From: Tim W. <ti...@sp...> - 2001-05-16 00:24:12
|
It's posted, linked from the lse home page. The direct URL is 'http://lse.sourceforge.net/lockhier/global-spin-lock'. Tim -- Tim Wright - ti...@sp... or ti...@ar... or tw...@us... IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI |
From: Christoph H. <hc...@ns...> - 2001-05-16 17:09:58
|
Hi, I think this list might be very interesting input for the kernel janitors. For the janitors not on lse-tech, the url of the refernced doc is http://lse.sourceforge.net/lockhier/global-spin-lock Christoph On Tue, May 15, 2001 at 11:28:56AM -0700, Rick Lindsley wrote: > I've produced the first draft of a document which can begin to describe > the locks in use in the Linux kernel, and I encourage the LSE community > to review it and send me comments. I've asked the maintainers of the > project to place it in a public location there so it can be easily > viewed. Although it's in plain text right now, it's over 1900 lines > long or I'd just include it in this message.) > > The philosophy of why I feel this document is necessary is explained in > the first few paragraphs of the document itself, so I won't repeat it > here. The document itself is more of a reference document than a paper, > but that's intentional for the first draft. Once we establish the > "correct" use of the various locks in use in the system, we can then > spend time discussing incorrect or unnecessary usages. Before we agree > on "correct" usage, such discussions can become quite philosophical. > > The goal of the review process, though, is to insure accuracy while > minimizing the impact to any one developer. Many of you who have > volunteered have other irons in the fire, and I want to use your time > efficiently. So I emphasize that I'm not asking any one person to > review the entire document -- please review those locks that you > believe you understand already and verify that I've interpreted them > correctly. Note that the r/w locks are only half finished; although I > believe there's only a few more hours work there, I really wanted to > get this out NOW and avoid putting it off while working on "just one > more thing." > > The remaining uses of the Big Kernel Lock are especially enigmatic. If > anyone feels qualified to comment on any remaining, legitimate uses for > the BKL, please do elaborate. My default belief, right now, is that all > the current uses are either incorrect, unnecessary, or due to be so > very soon (although I've not inserted this opinion into the document > quite so succinctly.) > > One more topic I encourage you to comment on is support. My original > intention was that this become a document submitted for inclusion in > usr/src/Documentation, and that it then be maintained on an ongoing basis > either by myself or another. (Yes I volunteer, initially.) If you have > thoughts on format, enhancements, or support issues please do include > that in your comments. Simply to provide a starting point, I'll take the > position right now that it be updated no more frequently than quarterly > and quite possibly less frequently. Updates will necessarily follow any > new release by a minimum of six weeks since I can't make the document > correct for any particular release until it is out and I have time to > go through it (or unless the release waits for me and I'm quite happy > to have Linux be the final gate on release thank you.) If you have other > thoughts or desires on support, by all means -- dissuade me. I'm fairly > open on this. > > Please send comments to ne...@se.... If that address causes > you problems for some reason, please try ne...@us.... That > address cannot reliably accept diffs currently due to possible message > reformatting, so a third address you may try if you need that > capability is ri...@ea.... > > Thank you in advance for your efforts. I encourage you to return > comments by 6/1 but will accept them both sooner and later. > > Rick Lindsley > IBM Linux Technology Center > ne...@se... > ne...@us... > ri...@ea... > > _______________________________________________ > Lse-tech mailing list > Lse...@li... > http://lists.sourceforge.net/lists/listinfo/lse-tech ---end quoted text--- |