Re: Yielding the processor in a kext?
Re: Yielding the processor in a kext?
- Subject: Re: Yielding the processor in a kext?
- From: Michael Smith <email@hidden>
- Date: Fri, 7 Sep 2007 14:00:54 -0700
On Sep 7, 2007, at 12:21 PM, Anton Altaparmakov wrote:
But for example from a file system kext we don't know what
priority the thread is and we don't own the thread either so we
should not be messing with priorities...
On the contrary. As a filesystem, if you need to perform a lengthy
task, the onus is on you to ensure that you do it on a thread with
an appropriate priority. If this means kicking off another thread,
so be it.
So I am going to spawn a kernel thread at a lower priority and block
in the parent thread until that thread completes?!? That makes no
sense whatsoever (at least to me)...
You want the task to be pre-empted if higher priority work arrives.
You don't know your current priority. Ergo, you give your work to a
pre-emptable thread of known priority.
[I am cheating in my example above as the lock taken by those code
paths at least for my FS kext is taken shared thus there is no
deadlock as both threads take the lock at the same time without
deadlocking but it was a simple example illustrating how sometimes
lock inversions happen because of antiquated interfaces that were
designed in a uniprocessor, no preemption, one funnel for all world
and not because of people's inability to write proper code...]
So fix the problem; don't cite it as an excuse for writing bad code...
And another example: In a critical path when a memory allocation
fails, I want to yield the CPU and try again later when the system
hopefully has more memory available as failing the allocation is a
disaster for file system consistency at this point. At the moment
I just do it in a busy loop trying again and again and again till
the scheduler decides to reschedule me. That's got to be totally
insane... )-:
You're right, it is. You should, instead, either:
a) Fail the operation with a resource shortage error.
Can't do that without leaving the FS in severe state of corruption.
Keeping state and rolling back is too much effort (resources wise it
would slow down things a lot) to be worth it for such an uncommon
case.
So fix your FS design; don't cite it as an excuse for writing bad
code...
b) Use one of the memory allocation primitives that knows how to
wait intelligently for memory to become available.
I have been told I should only be using OSMalloc()...
So fix the problem; don't cite it as an excuse for writing bad code...
Care to rewrite the VFS/VM <-> FS kext interface and fix up all file
systems? No? Me, neither...
I'd love to.
= Mike
_______________________________________________
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