lkml.org 
[lkml]   [1998]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.079 / U:1.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site