From owner-freebsd-current Sat Aug 8 22:25:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA12422 for freebsd-current-outgoing; Sat, 8 Aug 1998 22:25:41 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from rah.star-gate.com (rah.star-gate.com [209.133.7.234]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA12399 for ; Sat, 8 Aug 1998 22:24:19 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id WAA05274; Sat, 8 Aug 1998 22:22:50 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199808090522.WAA05274@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: John Birrell cc: jasone@canonware.com (Jason Evans), current@FreeBSD.ORG Subject: Re: SMP and kernel threads (Was: Re: Pthreads woes revisited.) In-reply-to: Your message of "Sat, 08 Aug 1998 08:57:58 +1000." <199808072257.IAA11353@cimlogic.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 Aug 1998 22:22:50 -0700 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Perhaps someone should gather all the necessary pieces and provide a kernel , or patches so that support for kernel threads can proceed forward as opposed to waiting two months to then start the 6 month estimated time to complete the task. For the benefit of those who missed John Dyson's recent posting here it is again: ---------------------------------------------------------------------------- dyson@iquest.net: I am working on Pthreads for work. However, I did get tied up trying to improve the SMP so that Pthreads work properly there. If someone distills the SMP patches that I had distributed and remove some of the buggy stuff, then the Pthreads should be closer to working, and when they do work, they'll work super-well. It wasn't so much the "next greatest improvement" but making the code work correctly on SMP (the problems weren't with JB's stuff, but with the structure that it was trying to work in.) So, given the goals of "good SMP" and "threads", and working within the existant kernel framework, it was a significant effort. Out of my patches, it would be a really good idea to grab the following: 1) prv_CMAP4,prv_CPAGE4, and the better prezero code. (Prezeros should be done on a private per-cpu mapping.) (vm_machdep, mp_machdep, pmap.) 2) The pmap (and tlb shootdown) improvements. (mp_machdep, apic_*, pmap.) 3) CPU affinity. (swtch.s) 4) Passing the vm_page_t into pmap instead of pa. (By doing so, it short circuits some really nasty code in pmap.) (vm_page, vm_object, vm_map, pmap, ...) 5) The improvements in vm_object and vm_map handling. (vm_map, vm_object.) 6) TLB update improvements for multi-threaded processes. (swtch.s) New things that MUST be done for reliable SMP on X86 (PPro's especially), and things NOT in my patches: 1) The TLB shootdown MUST be made synchronous!!! (I had experimental versions of that code.) Any non-synchronous TLB shootdowns on PPros is a non-starter. Some of the problems can be worked around by pre-setting the PG_A and PG_M bits, but that doesn't solve everything. Synchronous TLB shootdowns are a little bit tricky, due to the potential for deadlocks. However, the issues aren't impossible to solve, one just needs to be "aware." This starts pushing the code into being more correct regarding locking. 2) Correct the locking issues in vm_object -- it is horrendous (not just for fine-grained SMP.) Suggestions: 1) Make VM86 non-optional. 2) Make USER_LDT non-optional. I do have a tree of JB's work. I suspect that a significant percentage of SMP reliability problems are the TLB shootdown issue. I have known about these issues and more, and have only now had reason to explain what is going on -- since someone needs to pick-up some of these items. ---------------------------------------------------------------------------- Enjoy, Amancio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message