Date: Thu, 27 Mar 2003 22:24:51 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: Daniel Eischen <eischen@pcnet1.pcnet.com> Subject: Re: 1:1 threading. Message-ID: <Pine.BSF.4.21.0303272210340.65796-100000@InterJet.elischer.org> In-Reply-To: <20030327143259.I64602-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 27 Mar 2003, Jeff Roberson wrote: > > The effects are less because each thread/kse is given as big of a quantum > as each full process would. I'm not sure if this is a bug or a feature. > It's neither.. it's not what happens. More accuratly, it's only part of the story. Firstly it's 'standin' code.. but it exhibis some of the desired bahaviour. Yes, each KSE gets a quantum, but the next thread to run in that KSE is forced to go to the end of the queue. Effecively, this forces the process to allow other processes with enough priority to get CPU. This is a 'quick' solution to stopping a process with a lot of threads from swamping the system. The plan is to put in place a more comprehensive solution when time allows. Only one thread for each KSE can actually be on the run queue at a time.. yes it could run for the entire quantum, but the system will not let it put 10000 of these back to back unless there are no other competing threads. There is room there for a graduate student to do a project adding code to allow the KSEGRP to allow the rest of it's quantum to be passed on to other equivalent priority threads in the same group. This would be, as dicussed several times, in the form of code in choosethread() that would first check for internal threads if there was quantum left, before resorting to external threads to run. (The trick is to get the right balance)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0303272210340.65796-100000>