Date: Wed, 9 Oct 2002 01:04:47 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: arch@freebsd.org Subject: Re: Scheduler framework. Message-ID: <Pine.BSF.4.21.0210090041400.37238-100000@InterJet.elischer.org> In-Reply-To: <20021009020755.N44108-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 9 Oct 2002, Jeff Roberson wrote: [...] > what defines the parallelism of the application. Having two in the same > kseg on the same processor defeats that. Do you have any plans to > implement cpu binding? I have plans to plan it.. :-) > > > to do different things. > > > > Have you taken into account the KSE loaning that just went into the > > tree in the last week..? It's needed to stop deadlocks and starvation > > in some common cases. > > > > Nope, I haven't looked into that. It sounds like it would just make > performance a little worse by forcing a thread to temporarily migrate. No. that's not what it is.. consider.. thread A gets some resourse (X) and then blocks, causing an upcall that resuls in thread B running... thread B becomes BOUND to it's KSE (through one of several posible methods.. ) and then needs resource X. howeve A cannot proceed because the KSE is bound to B. KSE loaning allows the KSE to be given to A to complete its operation within the kernel, thereby allowing B to eventually be able to run again and claim back the KSE... basically teh life of a thread in a syscall is: If a thread mailbox is not provided: Thread is considered BOUND. blocking will not disassociate the KSE from the thread. While the thread is on the sleep queue, the KSE is still pointed to by the thread, and to visa versa (except for loaning..(see later).) When the thread is restarted, it continues with the same KSE (* that is important) and returns to userland directly as per normal. If a thread mailbox IS provided: the syscall is entered. the thread blocks. A second thread is invoked and attached to the KSE, which is disconnected from the original thread. the new thread is set to do an upcall, and since it must not create any more threads if IT blocks an dsince IT does not have a thread mailbox, the new thread and the KSE are bound together. The upcall goes to the user boundary. In thread_userret() the ksegrp is scanned for any runnable threads that need a KSE to complete. The upcalling thread is held to one side while the KSE is applied to each completing thread in turn, and they write their exit status back to their individual mailboxes. After the last one is finished, teh upcall is allowed to complete, and reports ALL the completed syscalls to the userland scheduler. At some time in the future the original thread is awoken and cannot proceed due to lack of KSE. THe nect time a KSE is available or henext time one tries to go to userland, the same scheme as described above happens and It aquires a KSE for long enough to run back o the user boundary and write it's completion status back to the mailbox. it then hands the KSE back t the owner who will upcall and report the completed thread. Note upcalls are BOUND BOUND threads Lend their KSEs when they block or cross to userland When there is no work to do, a borroed KSE reverts to it's "Owner" which continues (unless it is otherwise blocked). The lender will never restart with some other KSE while its KSE is lent out. A bound thread will ALWAYs use a particular KSE and can NEVER swap KSEs. An unbound thread can swap KSEs any time it likes. and when blocked, the KSe is free to run other threads EVEN to USERLAND. When it has no work to do it becomes idle. (on Idle queue) A Borrowed KSE can never go to userland. When it has no work to do it reverts to the owner thread and tries to run that. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0210090041400.37238-100000>