From owner-freebsd-current Fri Aug 7 14:14:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA25286 for freebsd-current-outgoing; Fri, 7 Aug 1998 14:14:05 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA25111 for ; Fri, 7 Aug 1998 14:13:20 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id QAA13383; Fri, 7 Aug 1998 16:12:13 -0500 (EST) (envelope-from toor) Message-Id: <199808072112.QAA13383@dyson.iquest.net> Subject: Re: Pthreads woes revisited. In-Reply-To: <199808070336.NAA03174@cimlogic.com.au> from John Birrell at "Aug 7, 98 01:36:31 pm" To: jb@cimlogic.com.au (John Birrell) Date: Fri, 7 Aug 1998 16:12:13 -0500 (EST) Cc: hasty@rah.star-gate.com, jb@cimlogic.com.au, shmit@kublai.com, current@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Birrell said: > Amancio Hasty wrote: > > Curious, whats missing from the kernel for us to have kernel threads? > > > > Perhaps John Dyson can help us out over here ... > > The last problem I was having was with the user_ldt being restored > on context switches. AFAIK John never built in the patches I sent him. > He was always preoccupied with the "next greatest improvement". > I ended up side-lining the work in favour of doing work on the Alpha > port. > 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. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message