> The problem was very quickly noticed as other students quickly learned
> how to make use of such "solutions" to their performance wants. We
> relatively quickly had to add process level accounting of thread CPU
> usage such that any thread in a process counted to that process's
> CPU usage/timeslice/etc. It basically made the scheduler into a
> 2-stage device - much like user threads but with the kernel doing
> the work and all of the benefits of kernel threads. (And did not
> require any code recompile other than those people who were doing
> the many-threads CPU hog type of thing ended up having to revert as
> it was now slower than the single thread-per-CPU code...)
Then you can just as well use fork(2) and split into processes with the
same result. The solution is not thread specific, it is resource limits
and/or per user cpu accounting.
Several raytracers can (could?) split the workload into multiple
processes, some being started on other computers over rsh or similar.
Peter
-- Peter Svensson ! Pgp key available by finger, fingerprint: <petersv@psv.nu> ! 8A E9 20 98 C1 FF 43 E3 07 FD B9 0A 80 72 70 AF ------------------------------------------------------------------------ Remember, Luke, your source will be with you... always...
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/