Paul Allen wrote: >>From Julian Elischer <julian_at_elischer.org>, Fri, Oct 27, 2006 at 03:34:21PM -0700: >> Lev Serebryakov wrote: >> basically, if you and I both write programs to do a particular job >> on a timesharing system, and you use threads to do so and I use >> a sophisticated event handler/state machine, I shouldn't find that >> my program is running like a pig because yours has 1000 slots in the >> run queue and I only get run 1 in 1001 ticks. > And if this hypothetical user with the 1000 threads instead uses 1000 > processes we should just look the other way? Or worse we should encourage > him to use processes instead of threads despite that the former ought > to consume more wall-time because of the extra overhead? > > The answer to your situation is rlimits. there is class of problems (e.g. some java programs) that have THOUSANDS of threads, each representing an active aspect of some object. How do you put an rlimit on that without either 1/ stopping the program from working or 2/ allowing thousands of threads to exist but not screwing other users. As I said.. the fairness aspect we have is a prototype and I hoped it would be replaced by something more sophisticated. It hasn't happenned. > > Or put another way, absent such limits, if I can keep 1000 threads busy > for the entire duration of your program, ipso facto I have more work to > do than you do. no, I might have the same amount of work to do too, but I only get 1 in 1001 slots to do it in.. > > I think what you are really saying is that you want an rlimit that allows > WFQ by uid/gid/login classes. It isn't necessary for such a thing to run > at the same frequency as the scheduler generally. correct. Though WFQ is not nearly the only game in town. > > > PaulReceived on Fri Oct 27 2006 - 21:32:25 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:01 UTC