I agree that the current code is a total mess (I have converted it to
the ipc/util.h helper functions, and I found further SMP and UP races)
_if_ I find a simple serialization, then I'll kill the semaphore.
> And I don't think the serialization is a performance problem, because
> by the time you start paging we're not talking about high performance
> shared memory anyway, and because it's per-segment it is notgoing to make
> "system" performance any worse.
>
What about a 100-gigabyte shm segment (on a 64-bit platform) with a fast
scsi disk system? The semaphore will prevent any tagged commands, and it
will downgrade (performance wise) the scsi system to a slow ide disk.
Btw, I'm sure that for multi-threaded applications, the mmap performance
of Linux will be poor because everything is single-threaded. I'll
write a benchmark and compare it with WinNT/Win95.
>
> In fact, my reaction to the semaphore is "do we actually need the
> spinlock any more"?
>
shm_swap() must not acquire a semaphore, or we could lock-up during
low-memory.
-- Manfred
- 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/