Re: cpu_number()
Re: cpu_number()
- Subject: Re: cpu_number()
- From: Ken Hornstein <email@hidden>
- Date: Fri, 19 Aug 2011 11:07:07 -0400
>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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden