News:
* big lock is taken inside the fput(). fput() can be called without
the big lock and the common path will not touch the big lock at all.
* some big lock shifting. Please, look through mm/* part. do_mmap()
still needs the big lock - there is an unrelated race waiting.
Interaction with mandatory locks, that is.
* races (present in 2.2.10 and 2.3.9-pre4) fixed on irix and
(partially) on sparc. I'll extract that part and will submit it to
Linus - races are *not* SMP-specific.
I think that this variant may be visibly faster. Large parts of mm/* are
taken out of the big lock. I think that file descriptors handling and
struct file handling are mostly OK now. Remaining problems sit in
arch/sparc64/solaris/timod.c and it seems to be full of races that have
nothing with SMP. Plus there are several places where we will need a
cosmetical changes for big file array support (kmod.c).
It may be buggy. It didn't get sufficient testing. It may screw your
disks, eat your filesystems, create accounts for Zumabot and C&S *and*
start posting - you've been warned. Said that, bug reports and comments
are more than welcome.
The next goal became obvious - fs/locks.c. We have a *big* contention
point there and it really doesn't scale well. Deadlock detection is nasty
- look what it does in posix_locks_deadlock(). Notice *multiple* scans of
the system-wide locks list. Essentially the current version does the
following:
next_task:
if (caller == blocker)
fail
for fl in all active locks
for bfl in all locks blocked by fl
if bfl is owned by blocker
if fl is owned by caller
fail
blocker = owner of fl
goto next_task
>From the reading of fs/locks.c it seems that keeping the list of *blocked*
locks with given owner would simplify the thing big way.
So there...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/