Re: Yielding the processor in a kext?
Re: Yielding the processor in a kext?
- Subject: Re: Yielding the processor in a kext?
- From: Anton Altaparmakov <email@hidden>
- Date: Fri, 7 Sep 2007 22:14:23 +0100
Hi,
On 7 Sep 2007, at 22:00, Michael Smith wrote:
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.
Surely the overhead of starting a thread would be far too high to
make such a thing worth doing?
[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...
Sorry but you cannot be talking seriously. Lets just say I had
nothing better to do and went and rewrote the OSX kernel you cannot
seriously be suggesting that I would not be totally wasting my time
as no-one would accept my new code as it would break backwards
compatibility/API/ABI/everything in existence. You can do that on
Linux (and such work is in fact ongoing to better support cluster
file systems!) but in the world of companies like Apple that would
never happen.
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...
This discussion is becoming pointless, sorry. It has nothing to do
with my FS design.
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...
What problem?
Care to rewrite the VFS/VM <-> FS kext interface and fix up all
file systems? No? Me, neither...
I'd love to.
Yes but aren't doing it as you know your changes would not be
accepted. So stop making impossible suggestions please! They are
not productive and just waste everyone's time (well ok, my time
reading and replying anyway)...
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/
_______________________________________________
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