On 4/8/06, Dean Anderson <[EMAIL PROTECTED]> wrote: > I'm building openafs 1.4.0 on Aurora 2.0 beta 2, which is essentially a linux > 2.6.13 kernel. I've just notice that there are no definitions for > > SPLVAR, > NETPRI > USERPRI >
IIRC, these were a holdover from uniprocessor days when netpri was sufficient to ensure mutual exclusion. They are not sufficient to provide safety on multiprocessors, so they have been removed. Most of the cache manager is protected by afs_global_lock. Much of Rx is protected by a bunch of afs_kmutex_t variables (on platforms where RX_ENABLE_LOCKS is defined; which I believe is most of them). > for use by the kernel module, for any linux variant. I saw a patch for > sparc64_linux26, which just had the effect of nulling out the locks, causing > it > to compile with no locking, which is may be fine on a uniprocessor (or not). > Is > is really safe to run afs on SMP or even UP kernels without locks? > People are running AFS on largish smp boxes, so I'd say it's safe to run on smp and preemptive UP kernels. Granted, we do discover deadlocks and races from time to time, but the code is mostly thread-safe. There is one major caveat: the code is mp-safe, NOT mp-fast. There are a bunch of afs_lock structs that protect broad subsystems of the cache manager. However, these are "pseudo-locks". There are no kernel mutexes associated with these structures. Instead, entry and exit to these locks is controlled by afs_global_lock. Thus, they provide a method of time division multiplexing without providing any MP speedup. Hope that helps, -Tom _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
