site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com
What are you really trying to do, and why do you think getting the CPU you were scheduled on a nanosecond ago while be correct a nanosecond from now?
Well, _since_ you asked ... One of my off-again, on again projects at work is porting Lustre (a high-performance network filesystem that right now only runs on Linux) to OS X. I've made some reasonable progress (it works, but poorly), but there are some things that are hard to make work as intended. One of the things Lustre does is log data into buffers for later debugging. To get rid of lock contention issues during logging what Lustre does is create a series of buffers for each CPU, and when you log something you log it into the buffer corresponding to your CPU. Now you will no doubt ask exactly how do you guarantee that you don't end up logging to the "wrong" CPU buffer? Well, on Linux as part of getting the CPU number you call the function preempt_disable(), which prevents your thread from getting preempted and pins it to the current CPU. When you're done logging your data you call preempt_enable(). My current solution is to simply return a CPU number of 0 for everything and the debug log gets corrupted. Right now I don't use it so it's not a huge deal, but it would be useful at some point to get it working. Now I think this is a reasonable thing to do in this particular case; it doesn't seem unusual to me. But it's not possible with the currently exported KAPIs. Of course there exists ml_preempt_disable() and cpu_number() in the internal kernel API; if those were exported, it would be exactly what I need. If you've got an alternate suggestion on how I could accomplish this, hey, I'd be glad to hear it. I know, I could take the hit and use a spinlock for those buffers, but depending on the configuration Lustre can log a lot of data and doing that could really hurt performance (I'll be the first to admit that the current client has lousy performance, but it's a work in progress!). Another thing to consider is that the eventual goal is to submit this to the open-source Lustre source, and the more changes I have to make to the Lustre sources, the harder the integration will be. That's not to say that Apple should implement every crazy Linux kernel API out there to make my life easier, but it does mean there's a limit as to how much I can change the Lustre code and still meet my long-term goals. --Ken _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com