Ingo Molnar wrote:Sure I started the discussion but I suppose you missed Andi's and other replies. All I said that people should think twice before relying on it. btw I'm ok if I _am_ the _one_ who has to convert those pieces of code, that's part of the fun :). But if people keep adding stuff which uses stom_machine that may be pretty difficult :). btw Being an RT guy you do not think that stop machine is evil ? I mean from the overhead and especially latency perspective. By overhead I mean if you have 100+ cpu box that Paul and other guys have mentioned here. Every single CPU has to be frozen. You said it's reasonably fast. I guess it depends what's reasonable. And from the latency perspective all bets are off. We have no guaranties whatsoever as to hold long it will take for cpu X to get frozen (there numerous factors here) and all the other cpus have to wait for it. As I said for some things there is just no other way but to use the stop_machine but we should try to minimize that as much as possible. Max --
| Linus Torvalds | Linux 2.6.27-rc8 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Linus Torvalds | Linux 2.6.20-rc6 |
| Mike Snitzer | Re: Distributed storage. |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Herbert Xu | Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state ch... |
