Re: Proposed fix for SMP vm_zeroidle.c
Peter Wemm wrote: > John Baldwin wrote: > > > > On 11-Jul-2002 Matthew Dillon wrote: > > > Here is my proposed fix for the page-zeroing problem w/ SMP. It > > > is untested (I'm about to test it)... I'm looking for comments on > > > the concept. If the comments are positive and my testing succeeds I > > > will commit it tonight. > > > > > > Basically the idea is simple. Provide a function that mi_switch() ca n > > > call when switching in a thread. The page zeroing code sets this > > > function to cpu_invlpg(CADDR3) on switch-in, thus dealing with any > > > potential switch between cpu's with virtually no overhead (no overhea d > > > that we care about anyway). > > > > > > I daresay that this mechanism could be used for a number of other > > > purposes as well. > > > > > > What do you think? > > > > Sounds fine to me. I'm not sure it will be all that useful for other > > things in the future but it conveniently solves the problem at hand > > at least. > > ARRGH!! N!!! To clarify, please hold fire for a day or so please. Let me finish validating what I'm working on now (I've been testing for three days). Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed fix for SMP vm_zeroidle.c
:ARRGH!! N!!! : :I've almost completely replaced this code! : :I suggested a function for activation a few days ago too, but was going :to leave it till after this commit, which I hoped to get done today. :This reactivates PG_G for SMP and avoids global invltlb's when we can :do finer grained shootdowns. : :Cheers, :-Peter :-- :Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Well, it only took me 5 minutes to whip up the fix, I can throw it away if you already have one. Could you post your zeroidle fix? -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed fix for SMP vm_zeroidle.c
John Baldwin wrote: > > On 11-Jul-2002 Matthew Dillon wrote: > > Here is my proposed fix for the page-zeroing problem w/ SMP. It > > is untested (I'm about to test it)... I'm looking for comments on > > the concept. If the comments are positive and my testing succeeds I > > will commit it tonight. > > > > Basically the idea is simple. Provide a function that mi_switch() can > > call when switching in a thread. The page zeroing code sets this > > function to cpu_invlpg(CADDR3) on switch-in, thus dealing with any > > potential switch between cpu's with virtually no overhead (no overhead > > that we care about anyway). > > > > I daresay that this mechanism could be used for a number of other > > purposes as well. > > > > What do you think? > > Sounds fine to me. I'm not sure it will be all that useful for other > things in the future but it conveniently solves the problem at hand > at least. ARRGH!! N!!! I've almost completely replaced this code! I suggested a function for activation a few days ago too, but was going to leave it till after this commit, which I hoped to get done today. This reactivates PG_G for SMP and avoids global invltlb's when we can do finer grained shootdowns. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Proposed fix for SMP vm_zeroidle.c
On 11-Jul-2002 Matthew Dillon wrote: > Here is my proposed fix for the page-zeroing problem w/ SMP. It > is untested (I'm about to test it)... I'm looking for comments on > the concept. If the comments are positive and my testing succeeds I > will commit it tonight. > > Basically the idea is simple. Provide a function that mi_switch() can > call when switching in a thread. The page zeroing code sets this > function to cpu_invlpg(CADDR3) on switch-in, thus dealing with any > potential switch between cpu's with virtually no overhead (no overhead > that we care about anyway). > > I daresay that this mechanism could be used for a number of other > purposes as well. > > What do you think? Sounds fine to me. I'm not sure it will be all that useful for other things in the future but it conveniently solves the problem at hand at least. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
