On Wed, 2005-07-13 at 08:47 +0200, Ingo Molnar wrote:
>
> downgrade_write() wasnt the main problem - the main problem was that for
> PREEMPT_RT i implemented 'strict' semaphores, which are not identical to
> vanilla kernel semaphores. The thing that seemed to impact XFS the most
> is the 'acquirer thread has to release the lock' rule of strict
> semaphores. Both the XFS logging code and the XFS IO completion code
> seems to release locks in a different context from where the acquire
> happened. It's of course valid upstream behavior, but without these
> extra rules it's hard to do sane priority inheritance. (who do you boost
> if you dont really know who 'owns' the lock?) It might make sense to
> introduce some sort of sem_pass_to(new_owner) interface? For now i
> introduced a compat type, which lets those semaphores fall back to the
> vanilla implementation.
There's a lot of code like this in there .. I've seen some that down()
in process contex, and up() in interrupt contex which is weird .. But
those aren't major features, just little drivers. XFS is pretty major
feature.
Nathan, does XFS need this property or could we convert it to
synchronize the locking (with ease?)?
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |