Messages in this thread | | | Date | Tue, 3 Feb 1998 10:21:19 +0100 | From | Martin von Loewis <> | Subject | Re: threaded FS-drivers |
| |
> Well, there are two kinds of multithreading here. The Linux VFS, for > example, supports multiple processes inside the VFS, but only one of > them may execute at any time, i.e. only one *processor*.
I wonder what needs to be done to remove this restriction. Is it worth the effort to allow the VFS code to execute on multiple processors? If so, what needs to be done?
For example, I could imagine that most file systems would support concurrent access to different volumes (i.e. except for those that save state in global variables instead of the superblock). So all the system calls could acquire a per-superblock lock instead of the kernel lock, if the filesystem indicates it does not need the kernel lock.
This would eventually require the disk drivers to support the same level of concurrency. In 2.1.8x, what would break if you'd stop acquiring the kernel lock on, say, sys_read?
OTOH, what would you gain? I imagine that this is only worth the effort if large amounts of computing cycles are spent in the VFS. Of all the computing power wasted inside the kernel, which subsystem consumes most of it? (and yes, computing power used in the kernel is wasted - the user processes are the ones that are supposed to burn cycles)
Regards, Martin
| |