Stephen Tweedie writes:
> Indeed. Correct locking for the block allocator can in fact be
> achieved assuming no more than the big kernel lock. The main
> reason for the superblock lock is to manage the bitmap cache over
> IO operations.
What would be good for ext2 is a "group" lock similar to XFS, so that
block/inode bitmap allocation could be done in parallel. Currently, the
normal ext2 situation is that a directory, files in that directory,
and the file blocks are located in a single group, so the common case
you would only need to hold the lock on a single group in order to
create/extend/trucate/delete a file. This would make the searching for
free inodes/blocks (the O(n) part of the allocation) parallelizable,
and you would update the GDT at that time. You would only then need
to hold the superblock lock for a brief instant to update the free
blocks/inodes counter there (which is O(1)).
For cases where you need to allocate an inode/block in another group,
you would simply search all of the groups for one that didn't currently
have a lock. This would probably benefit performance as well, as groups
that had very busy files/directories in them would be bypassed during
allocation, as they would be locked, and groups that were not busy would
be chosen for new allocations as they would not be locked as often.
This would truly distribute _IO load_ across the groups, rather than
the current situation of estimating the load by how many directories a
group has.
Group locking order would be from lowest to highest group number to
avoid deadlocks in those cases where you _have_ to lock specific groups.
If you started with a lock on the lowest group number, you would wait
for the higher group locks in order. If you need a lock on a lower
group number, you need to release all of your locks and start at the
lowest number. You would need mutliple group locks, for example, if you
are deleting a directory in one group, and its parent is in another group
(a common case), or if a file was created in one directory, hard linked
to another directory in a different group, and then removed from the
original directory.
I guess the real question is if the VFS inherently serializes access
to a filesystem (which the big kernel lock would do), how hard would it
be to change the VFS to allow multi-threaded filesystem access? It
would probably require that the "lock_super" operation become atomic,
and probably a lot more.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
-
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/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:15 EST